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1.  INTRODUCTION 

This  paper  investigates  an  approach  to  increase  the  expressiveness  and  flexibility  of 
object-oriented  languages,  with  the  goal  of  improving  the  reliability  of  software.  By 
introducing  typestate  directly  into  the  language  and  extending  its  type  system  with 
support  for  gradual  typing,  useful  abstractions  can  be  implemented  directly,  stronger 
program  properties  can  be  enforced  statically,  and  when  necessary  dynamic  checks  can 
be  introduced  seamlessly. 

An  object’s  type  specifies  the  methods  that  can  be  called  on  it.  In  most  programming 
languages,  this  type  is  constant  throughout  the  object’s  lifetime,  but  in  practice,  the 
methods  that  it  makes  sense  to  call  on  an  object  change  as  its  runtime  state  changes 
(e.g.,  an  open  file  cannot  be  opened  again).  These  constraints  typically  lie  outside  the 
reach  of  standard  type  systems,  and  unintended  uses  of  objects  result,  at  best,  in  run¬ 
time  exceptions. 

More  broadly,  types  generally  denote  properties  that  hold  without  change,  and  in 
mainstream  type  systems,  they  fail  to  account  for  how  changes  to  mutable  state  can  af¬ 
fect  the  properties  of  an  object.  To  address  this  shortcoming,  Strom  and  Yemini  [1986] 
introduced  the  notion  of  typestate  as  an  extension  of  the  traditional  notion  of  type. 
Typestate  reflects  how  the  legal  operations  on  imperative  objects  can  change  at  run¬ 
time  as  their  internal  state  changes. 

The  seminal  work  on  typestate  [Strom  and  Yemini  1986]  focused  primarily  on 
whether  variables  were  properly  initialized,  and  presented  a  static  typestate  checker.  A 
typestate  checker  must  account  for  the  flow  of  data  and  control  in  a  program  to  ensure 
that  objects  are  used  in  accordance  with  their  state  at  any  given  point  in  a  computa¬ 
tion.  Since  that  original  work,  typestate  has  been  used  to  codify  and  check  more  so¬ 
phisticated  state-dependent  properties  of  object-oriented  programs.  It  has  been  used, 
for  instance,  to  verify  object  invariants  in  .NET  [DeLine  and  Fahndrich  2004],  to  verify 
that  Java  programs  adhere  to  object  protocols  [Fink  et  al.  2008;  Bierhoff  et  al.  2009; 
Bodden  2010],  and  to  check  that  groups  of  objects  collaborate  with  each  other  according 
to  an  interaction  specification  [Naeem  and  Lhotak  2008;  Jaspan  and  Aldrich  2009]. 

Most  imperative  languages  cannot  express  typestates  directly:  rather,  typestates  are 
encoded  through  a  disciplined  use  of  member  variables.  For  instance,  consider  a  typical 
object-oriented  file  abstraction.  A  closed  file  may  have  a  null  value  in  its  file  descriptor 
field.  Accordingly,  the  close  method  of  the  file  object  first  checks  if  the  file  descriptor  is 
null,  in  which  case  it  throws  an  exception  to  signal  that  the  file  is  already  closed.  Such 
typestate  encodings  hinder  program  comprehension  and  correctness.  Comprehension 
is  hampered  because  the  protocols  underlying  the  typestate  properties,  which  reflect 
a  programmer’s  intent,  are  at  best  described  in  the  documentation  of  the  code.  Also, 
typestate  encodings  cannot  guarantee  by  construction  that  a  program  does  not  perform 
illegal  operations.  Checking  typestate  encodings  can  be  done  through  a  whole-program 
analysis  (e.g.  [Fink  et  al.  2008]),  or  with  a  modular  checker  based  on  additional  pro¬ 
gram  annotations  (e.g.  [Bierhoff  and  Aldrich  2007]).  In  either  case,  the  lack  of  integra¬ 
tion  with  the  programming  language  hinders  adoption  by  programmers. 

To  overcome  the  shortcomings  of  typestate  encodings,  a  typestate-oriented  program¬ 
ming  (TSOP)  language  directly  supports  expressing  them  [Aldrich  et  al.  2009].  For  in¬ 
stance,  in  a  class-based  language  that  supports  dynamically  changing  an  object’s  class 
(such  as  Smalltalk),  typestates  can  be  represented  as  classes  and  can  be  dynamically 
updated:  objects  can  have  typestate-dependent  interfaces,  behaviors,  and  representa¬ 
tions.  Protocol  violations  in  a  dynamically-typed  TSOP  language  however  result  in 
“method  not  found”  errors.  To  catch  such  errors  as  early  as  possible,  we  want  to  regain 
the  guarantees  provided  by  static  type  checking. 
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Static  typestate  checking  is  challenging,  especially  in  the  presence  of  aliasing. 
Some  approaches  sacrifice  modularity  and  rely  on  whole  program  analyses  [Fink 
et  al.  2008;  Naeem  and  Lhotak  2008;  Bodden  2010];  others  retain  modularity  at  the 
expense  of  sophisticated  type  systems,  typically  based  on  linear  logic  [Walker  2005] 
and  requiring  many  annotations.  One  kind  of  annotations  is  access  permissions,  which 
specify  certain  aliasing  patterns  [Boyland  2003;  DeLine  and  Fahndrich  2004;  Bierhoff 
and  Aldrich  2007].  None  of  these  approaches,  however,  incorporates  typestates  as  a 
core  language  concept. 

The  first  contribution  of  this  paper  is  a  core  calculus  for  typestate-oriented  pro¬ 
gramming  inspired  by  Featherweight  Java  [Igarashi  et  al.  2001],  called  Featherweight 
Typestate  (FT).  FT  is  a  nominal  object-oriented  language  with  mutable  state  that  in¬ 
tegrates  typestate  change  and  typestate  checking  as  primitive  concepts.  Much  like  FJ, 
which  characterizes  Java  and  nominal  object-oriented  programming,  Featherweight 
Typestate  is  meant  to  precisely  characterize  TSOP  and  to  serve  as  a  platform  for  ex¬ 
ploring  extensions  to  the  paradigm  and  interactions  with  proven  and  bleeding-edge 
language  features.  A  novel  flow-sensitive  permission-based  type  system  makes  it  pos¬ 
sible  to  modularly  check  FT  programs. 

Unfortunately,  FT  and  all  existing  static  typestate  checkers  cannot  always  verify 
safe  code,  due  to  the  conservative  assumptions  they  must  make.  Advanced  techniques 
like  fractional  permissions  [Boyland  2003]  increase  the  expressiveness  of  a  type  sys¬ 
tem,  within  limits,  but  increase  its  complexity.  Many  practical  languages  already  pro¬ 
vide  a  simple  feature  for  overcoming  the  limitations  of  their  type  systems:  dynamic 
coercions.  Although  these  coercions  ( a.k.a .  casts)  may  fail  at  runtime,  they  are  often 
necessary  in  specific  scenarios  where  the  static  machinery  is  insufficient.  Runtime  as¬ 
sertions  about  typestates  are  not  supported  by  any  modular  approach  we  know  of;  one 
primary  objective  of  this  work  is  to  support  them. 

Once  dynamic  coercions  on  typestates  are  available,  they  can  be  used  to  ease  the 
transition  from  dynamically-  to  statically-typed  code.  For  this  reason,  we  extend  grad¬ 
ual  typing  [Siek  and  Taha  2006,  2007]  to  account  for  typestates:  we  make  typestate 
annotations  optional,  check  as  much  as  possible  statically,  and  automatically  insert 
runtime  checks  into  programs  where  needed.  This  allows  programmers  to  gradually 
annotate  their  code  and  get  progressively  more  support  from  the  type  checker,  while 
still  being  able  to  safely  run  a  partially-annotated  program. 

The  second  contribution  of  this  work  is  Gradual  Featherweight  Typestate 
(GFT),  an  extension  of  FT  that  supports  dynamic  permission  checking  and  gradual 
typing.  Like  FT,  GFT  directly  integrates  typestate  as  a  first-class  language  concept. 
Its  analysis  is  modular  and  safe  without  imposing  complex  notions  like  fractional  per¬ 
missions  onto  programmers.  It  supports  recovery  of  precise  typing  using  dynamically- 
checked  assertions,  supports  the  gradual  addition  of  type  annotations  to  a  program, 
and  enables  permission-  and  typestate-based  reasoning  in  dynamically  typed  pro¬ 
grams. 

Section  2  introduces  the  key  elements  of  typestate-oriented  programming  with  ac¬ 
cess  permissions  and  state  guarantees.  Section  3  describes  Featherweight  Typestate, 
including  its  syntax,  static  and  dynamic  semantics,  and  its  metatheory.  Section  4 
extends  FT  to  Gradual  Featherweight  Typestate.  GFT’s  dynamic  semantics  are  pre¬ 
sented  using  a  type-safe  internal  language  to  which  GFT  translates.  The  soundness 
proofs  for  both  languages  are  available  in  companion  technical  reports  [Garcia  et  al. 
2013;  Wolff  et  al.  2013].  Section  5  relates  the  dynamic  semantics  of  FT  to  that  of  GFT. 
In  particular,  every  FT  program  is  also  a  GFT  program,  and  its  translation  to  GFTIL 
has  the  same  runtime  behavior  as  running  the  FT  program  directly.  This  connection 
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Fig.  1:  (a)  State  diagram  of  a  file,  (b)  Hierarchy  of  files  states. 

is  analogous  to  the  relationship  between  the  simply  typed,  gradually  typed,  and  cast- 
based  languages  of  [Siek  and  Taha  2006].  Section  6  concludes.  A  translator  for  GFT’s 
source  language,  type  checker  for  the  internal  language,  and  executable  runtime  se¬ 
mantics  are  available  at: 
http://www.cs.ubc.ca/~rxg/gft/gft-toplas.tgz.1 

2.  TYPESTATE-ORIENTED  PROGRAMMING 

In  order  to  avoid  conditionals  on  flag  fields  or  other  indirect  mechanisms  like  the 
State  pattern  [Gamma  et  al.  1994],  typestate-oriented  programming  proposes  to  ex¬ 
tend  object-oriented  programming  with  an  explicit  notion  of  state  (from  here  on  we  use 
state  to  mean  typestate).  In  TSOP,  objects  are  modeled  not  just  in  terms  of  classes,  but 
in  terms  of  changing  states.  Each  state  may  have  its  own  representation  and  methods, 
which  may  transition  the  object  to  new  states. 

To  illustrate  this  concept  in  practice,  consider  a  familiar  example.  A  file  object  has 
methods  such  as  open,  close  and  read.  However,  these  methods  cannot  be  called  at 
just  any  time.  A  file  can  only  be  read  after  it  has  been  opened;  if  we  reach  the  end-of- 
file,  then  reading  is  not  available  anymore;  an  open  file  cannot  be  opened  again,  etc. 
Figure  la  shows  a  state  diagram  of  a  file  object,  describing  the  protocol.  Figure  lb 
depicts  the  corresponding  TSOP  model  of  file  objects  in  terms  of  states,  using  distinct 
classes  in  a  subclass  hierarchy  to  represent  states.  File  is  an  abstract  state;  a  file 
object  is  either  in  the  OpenFile  or  ClosedFile  state.  Note  that  the  path  field  is  present 
in  both  states,  but  that  the  file_desc  field,  which  refers  to  the  low-level  operating 
system  resource,  is  only  present  in  the  OpenFile  state.  Any  OpenFile  can  be  closed; 
however,  it  is  only  possible  to  read  from  an  open  file  if  the  end-of-file  has  not  been 
reached.  Therefore,  the  OpenFile  state  has  two  refining  substates,  AtEOF  and  NotEOF. 

State  change.  A  Typestate-oriented  programming  language  supports  a  state  change 
operation,  denoted  .  For  instance,  the  close  method  in  OpenFile  can  be  defined  as: 

void  close()  {  this  <—  ClosedFile(this.path) ;  } 

The  expression  form  e  <—  C( .  . . )  transitions  the  object  described  by  e  into  the  state  C; 
the  arguments  are  used  to  initialize  the  fields  of  the  object.  In  other  words,  <—  behaves 
like  a  constructor,  but  updates  the  object  in-place. 


1  An  earlier  version  of  this  article  was  presented  at  the  European  Conference  on  Object-Oriented  Program¬ 
ming  (ECOOP),  July  2011  [Wolff  et  al.  2011],  This  paper  differs  from  our  previous  article  in  a  number  of 
ways.  Most  importantly,  we  present  the  static  language  Featherweight  Typestate  (FT)  in  Section  3.  Gradual 
Typestate’s  type  system  is  simplified  to  more  clearly  reflect  its  foundations  and  its  relation  to  FT. 
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Fig.  2:  Access  permissions. 

Declaring  state  changes.  A  statically-typed  TSOP  language  must  track  state  changes 
in  order  to  reject  programs  that  invoke  methods  on  objects  in  inappropriate  states. 
Consider  the  following: 

OpenFile  f  =  ...;  f. closet);  f. closet); 

The  type  of  f  before  the  first  call  to  close  is  OpenFile.  However,  the  second  call  to 
close  should  be  rejected  by  a  type  checker.  One  way  to  do  so  is  to  analyze  the  body  of 
the  close  method  to  deduce  that  it  updates  the  state  of  its  argument  to  ClosedFile. 
However,  this  approach  sacrifices  modularity.  Therefore,  a  method’s  signature  should 
specify  the  output  state  of  its  arguments  as  well  as  that  of  its  receiver.  The  calculi  in 
this  paper  specify  the  state  changes  of  methods  by  annotating  each  argument  with  its 
input  and  output  state,  separated  by  the  »  symbol.  The  input  and  output  states  of  the 
receiver  object  are  placed  in  square  brackets  after  the  normal  argument  list,  e.g.: 

void  close()  [OpenFile  »  ClosedFile]  {...} 

Access  permissions.  In  a  language  with  aliasing,  tracking  state  changes  is  a  subtle 
process.  For  instance,  consider  the  following  (where  F,  OF  and  CF  are  abbreviations  for 
File,  OpenFile  and  ClosedFile,  respectively): 

void  m(0F  »  CF  f,0F  »  OF  g)  (f.closeO;  print(g.file_desc.pos) ;} 

Because  of  possible  aliasing,  f  and  g  may  refer  to  the  same  object.  In  that  case,  the 
method  body  of  m  must  not  be  well-typed,  as  g  may  refer  to  a  closed  file  by  the  time  it 
needs  to  access  its  (potentially  non-existent)  file_desc  field. 

To  track  state  changes  in  the  presence  of  aliasing,  Bierhoff  and  Aldrich  have  pro¬ 
posed  access  permissions  [Bierhoff  and  Aldrich  2007;  Bierhoff  et  al.  2009],  An  access 
permission  specifies  whether  a  given  reference  to  an  object  can  be  used  to  change  its 
state  or  not,  as  well  as  the  access  permissions  that  other  aliases  to  the  same  object 
might  have.  In  this  work  we  consider  three  kinds  of  access  permissions  (Figure  2):  full, 
shared  and  pure.  We  say  a  reference  has  write  access  if  it  has  the  ability  to  change  the 
state  of  an  object,  full  and  shared  have  write  access,  where  full  implies  exclusive  write 
access.  Our  choice  of  permissions  captures  a  coherent  and  self-contained  set  from  the 
literature  that  supports  common  programming  idioms.  We  can  easily  add  more  known 
permissions  (e.g.,  immutable,  unique,  and  none),  but  they  would  simply  add  more  com¬ 
plexity  to  our  development  without  providing  any  new  insights. 

One  fix  for  the  m  method  is  to  require  that  f  and  g  have  exclusive  write  access  to  an 
OF  in  order  to  ensure  that  they  are  not  aliases,  and  therefore  that  f.closeO  cannot 
affect  g’s  referent. 

void  m(full  OF  »  full  CF  f,  full  OF  »  full  OF  g){  ...  } 
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State  guarantees.  Requiring  g  to  have  exclusive  write  access  seems  like  overkill  here. 
Only  a  pure  access  permission  is  required  to  read  the  field  file_desc.  But  we  must  still 
ensure  that  the  two  parameters  are  not  aliases. 

For  more  flexible  reasoning  in  the  presence  of  aliasing,  access  permissions  are  aug¬ 
mented  with  state  guarantees  (proposed  by  Bierhoff  and  Aldrich  [2007]  but  formalized 
and  proven  sound  for  the  first  time  here).  A  state  guarantee  puts  an  upper  bound  on 
the  state  change  that  may  be  performed  by  a  reference  with  write  access:  it  can  only 
transition  an  object  to  some  subclass  of  the  state  guarantee.  A  type  specification  then 
has  the  form  k(D)  C,  where  k  is  the  access  permission,  D  is  the  state  guarantee,  and  C 
is  the  current  state  of  the  object.  A  permission,  k(D),  is  the  access  permission  coupled 
with  the  state  guarantee. 

Consider: 

full(Object)  NotEOF  x  =  new  NotE0F( . . . ) ; 
pure(OF)  OF  y  =  x; 
x.  reacl( ) ; 

print(y.file_desc.pos) ; 

While  x.  read( )  may  change  the  state  of  the  file  by  transitioning  it  to  AtEOF,  the  type 
system  ensures  that  it  cannot  invalidate  the  open  file  assumption  held  by  y. 

State  guarantees  improve  modular  reasoning  about  typestates  substantially.  For  in¬ 
stance,  they  recover  the  ability  to  express  something  similar  to  an  ordinary  object- 
oriented  type:  shared  (C)  C  allows  an  object  to  be  updated  but  guarantees  that  it  always 
obeys  the  interface  C.2  Also,  it  turns  out  that  we  can  use  state  guarantees  to  express 
an  alternative  solution  to  the  previous  example:  restrict  g  to  the  pure  access  permis¬ 
sion  it  requires,  but  add  a  state  guarantee  of  OF  to  ensure  that  no  other  reference  can 
transition  the  object  toClosedFile: 

void  m(full(F)  OF  »  full(F)  CF  f, 

pure(OF)  OF  »  pure(OF)  OF  g){  ...  } 

In  this  case,  we  can  still  statically  enforce  that  f  and  g  are  not  aliases  by  carefully 
choosing  exactly  how  references  to  objects  can  be  created.  In  this  way,  we  can  allow  the 
programmer  more  flexibility  than  always  demanding  exclusive  access  to  objects. 

Permission  flows.  Permissions  are  split  between  all  aliases  and  carefully  restricted 
to  ensure  safety.  This  includes  aliases  in  local  variables,  as  well  as  in  object  fields. 
Consider  the  following  snippet: 

class  FileContainerf  shared(OF)  OF  file;  } 

full(Object)  OF  x  =  new  OF ( . . . ) ; 
pure(OF)  OF  y  =  x; 

full(Object)  FileContainer  z  =  new  FileContainer(x) ; 

After  construction  of  the  OF,  the  reference  x  has  no  aliases,  so  it  is  safe  to  give  it  full  ac¬ 
cess  permission  with  an  unrestricted  update  capability  (Ob  j  ect  state  guarantee).  Then, 
a  local  alias  y  is  created,  capturing  a  pure  access  permission  with  OF  guarantee.  After 
this  point,  any  state  change  done  through  x  must  respect  this  guarantee.  Therefore,  the 
permission  of  x  must  be  downgraded  to  full  (OF) .  Finally,  a  container  object  is  created, 


2  In  FT,  state  guarantees  are  enforced  for  the  rest  of  program  execution.  As  we  will  see,  however,  when  we 
consider  gradual  typing,  a  guarantee  can  be  removed  if  the  variable  of  the  guaranteed  type  goes  out  of  scope, 
or  a  run-time  assertion  on  that  variable  is  executed.  Extensions  such  as  borrowing  can  also  allow  guarantees 
(e.g.  on  a  borrowed  object)  to  be  removed. 
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passing  x  as  argument  to  the  constructor.  The  field  of  z  captures  a  shared  (OF)  permis¬ 
sion.  The  permission  of  x  is  downgraded  again,  this  time  to  shared  (OF).  At  this  point, 
there  are  three  aliases  to  the  same  file  object:  x  and  z .  file  both  hold  a  shared  (OF)  per¬ 
mission,  and  y  holds  a  pure  (OF) .  All  aliases  must  be  consistent,  in  that  a  state  update 
through  one  alias  must  not  break  the  invariants  of  other  references. 

Temporarily  holding  permissions.  Consider  the  example  of  a  socket.  A  socket  (of  type 
S)  is  like  a  file  in  that  it  can  be  open  (OS)  or  closed  (CS).  However,  an  open  socket  can 
also  be  ready  (RS)  or  blocked  (BS).  The  wait  method  accepts  a  blocked  socket  and  waits 
until  it  is  ready,3  while  the  read  method  gets  data  from  the  socket.  The  methods  of 
socket  have  the  following  signatures: 

void  wait()  [  pure (OS)  OS  »  pure (OS)  RS] 
int  read()  [shared(OS)  RS  »  shared(OS)  OS] 

Now  consider  the  following  program,  which  waits  on  a  blocked  socket  and  then  reads 
from  it: 

shared(OS)  OS  x  =  new  0S(...); 
x.wait() ; 
x. read( ) ; 

This  program  is  ill-typed  due  to  the  downgrading  of  permissions.  In  order  to  invoke 
wait,  the  permission  to  x  is  downgraded  from  shared  (OS)  OS  to  pure  (OS)  OS.  Therefore, 
read,  which  requires  a  shared  (OS)  RS,  cannot  be  called,  even  though  the  call  to  read 
is  safe:  wait  requires  a  read-only  alias  to  its  argument,  and  does  nothing  that  would 
interfere  with  the  caller’s  shared(OS)  permission.  This  is  an  unfortunate  limitation 
due  to  the  conservative  nature  of  the  type  system. 

We  could  attempt  to  work  around  this  problem  by  creating  a  temporary  alias  to  x 
with  only  a  pure  access  permission,  and  use  that  alias  to  invoke  wait.  This  is  however 
cumbersome  and  does  not  allow  for  permissions  to  be  merged  back  later.  Merging  the 
permission  returned  by  wait  into  the  permission  held  by  the  client  is  crucial  in  this 
case,  because  we  want  x  to  have  type  shared(OS)  RS,  taking  advantage  of  the  fact  that 
wait  returns  when  the  socket  is  ready  (RS). 

In  order  to  properly  support  this  pattern,  we  introduce  a  novel  expression,  hold, 
which  reserves  a  permission  to  a  variable  for  use  within  a  lexical  scope,  and  then 
merges  that  permission  with  that  of  the  variable  at  the  end  of  the  scope.  For  instance: 

shared(OS)  OS  x  =  new  0S(...); 
hold[x:shared(OS)  OS]  {  x.wait();  } 
x. read( ) ; 

The  program  is  now  type  correct:  hold  retains  a  shared  access  permission  to  the  object 
referenced  by  x,  which  is  merged  back  once  the  body  of  hold  is  evaluated.  The  call  to 
wait  is  performed  with  just  the  necessary  access  permission,  pure,  and  the  state  of 
the  object  is  merged  back  into  the  permission  of  x,  enabling  the  call  to  read.  Our  hold 
construct  serves  a  similar  purpose  to  borrowing  [Boyland  and  Retert  2005;  Naden  et  al. 
2012],  in  that  it  can  be  used  to  ensure  that  the  caller  retains  the  permissions  it  needs 
after  making  a  method  call.  The  two  differ  in  that  borrowing  ensures  the  callee  returns 
all  of  the  permissions  that  it  was  given  without  storing  any  in  the  heap.  In  contrast 
hold  is  for  the  caller  only:  the  callee  can  do  what  it  wants  with  the  permissions  it 
receives  so  long  as  sufficient  permissions  are  returned  to  the  caller. 


3Note  that  wait  does  not  actually  change  the  state  of  the  socket  itself,  but  rather  asserts  the  desired  RS  type 
once  the  state  of  the  socket  has  been  changed,  e.g.  by  another  thread  or  by  a  coroutine. 
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Dynamic  permission  asserts.  As  sophisticated  as  the  type  system  might  be,  it  is  still 
necessarily  conservative  and  therefore  loses  precision.  Dynamic  checks,  like  runtime 
casts,  are  often  useful  to  recover  such  precision.  For  instance,  consider  the  following 
extension  of  the  FileContainer  snippet  seen  previously  in  which  both  y  and  z  are  up¬ 
dated  to  release  their  aliases  to  x. 

y  =  new  OF ( . . . ) ; 
z  <—  ObjectO  ; 
assert<full(F)  0F>(x); 
x. close!) ; 

Assuming  close  requires  a  full  ( F )  permission  to  its  receiver,  the  type  system  is  unable 
to  determine  that  x  can  be  closed,  even  though  it  is  safe  to  do  so  (because  x  is  once 
again  the  sole  reference  to  the  object).  A  dynamic  assert  allows  this  permission  to  be 
recovered.  Like  casts,  dynamic  asserts  may  fail  at  runtime. 

Note  that  dynamic  class  asserts,  which  modify  the  static  class  of  an  object  but  leave 
permissions  alone,  need  no  special  support  beyond  what  is  needed  for  a  typical  object- 
oriented  language.  Therefore,  a  static  typestate  language  that  runs  on  a  standard  00 
backend  can  support  dynamic  assertions  about  the  class  of  an  object.  Dynamic  permis¬ 
sion  asserts,  on  the  other  hand,  require  special  support  from  the  runtime  system. 

Gradual  typing.  A  statically-typed  TSOP  program  requires  more  annotations  than 
a  comparable  object-oriented  program.  This  may  be  prohibitively  burdensome  for  a 
programmer,  especially  during  the  initial  stages  of  development.  For  this  reason,  we 
develop  a  gradually-typed  calculus  that  supports  a  dynamic  type  Dyn.  Precise  type 
annotations  can  then  be  omitted  from  an  early  draft  of  a  program  as  in  the  following 
code: 

Dyn  f  =  . . . ;  f . read! ) ; 

A  runtime  check  verifies  that  f  refers  to  an  object  that  has  a  read  method4.  Assume 
that  read  is  annotated  with  a  receiver  type  full(OF)  NotEOF.  In  this  case,  we  must 
ensure  that  we  have  an  adequate  permission  to  the  receiver.  Thus,  a  further  runtime 
check  verifies  that  f  refers  to  an  object  that  is  currently  in  the  NotEOF  state,  that  no 
aliases  have  write  access,  and  that  all  aliases  have  a  state  guarantee  that  is  a  su¬ 
perstate  of  OF.  The  last  two  conditions  ensure  that  invariants  of  aliases  to  f  cannot 
be  broken.  Gradual  typing  thus  enables  dynamically  and  statically-typed  parts  of  a 
program  to  coexist  without  compromising  safety. 

While  typestate  checking  has  historically  been  considered  only  in  a  fully  static  set¬ 
ting,  supporting  gradual  typestate  checking  means  that  access  permissions  and  state 
guarantees  are  properties  that  are  dynamically  enforced.  Just  like  objects  have  refer¬ 
ences  to  their  class,  object  references  have  both  access  permissions  and  state  guaran¬ 
tees.  For  instance: 

Dyn  x  =  app . getFile! ) ; 
pure(OF)  OF  y  =  x; 
app . process (x) ; 

x  is  a  dynamic  reference  to  a  file,  and  remains  so  even  after  a  statically-typed  alias  y 
is  created.  However,  the  static  assumptions  made  by  y  are  dynamically  enforced:  both 
x  and  y  refer  to  (at  least)  an  open  file  after  the  execution  of  process.  If  process  tries  to 
close  x,  an  error  is  raised. 


4Note  that  Dyn  is  different  from  Object:  if  f  had  type  Object  then  type  checking  would  fail  because  Object 
has  no  read  method. 
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Putting  it  all  together.  Listing  1  exhibits  the  above  capabilities  in  a  small  logging 
example  that  generalizes  to  other  shared  resources5.  The  OpenFileLogger  (OFL)  state 
holds  a  reference  to  a  file  object  (OF)  and  provides  a  log  method  for  logging  messages  to 
it.  When  logging  is  complete,  the  close  method  acquires  all  permissions  to  the  file  by 
swapping  in  a  sentinel  value6  (with  explained  in  the  next  section),  closes  the  file, 
and  transitions  the  logger  to  the  FileLogger  (FL)  state,  which  has  no  file  handle.  The 
client  code  declares  and  uses  two  logging  interfaces,  staticLog  and  dynamicLog.  They 
are  somewhat  contrived,  but  are  meant  to  represent  APIs  that  utilize  a  file  logger 
but  do  not  store  it.  After  creating  logger  (line  23),  the  filed  reference  no  longer  has 
enough  permission  to  close  the  file,  so  calls  to  logger. log ()  are  safe.  Line  25  passes 
logger  to  a  dynamically-typed  method;  as  a  result,  logger  is  of  type  Dyn  after  the  call. 
Using  hold,  we  hold  a  shared  (OFL)  OFL  permission  to  the  logger  while  the  dynamicLog 
call  happens,  then  restore  those  permissions  before  the  call  to  staticLog.  Had  we  not 
held  these  permissions,  the  logger  would  have  Dyn  type,  and  the  call  to  staticLog () 
(line  26)  would  be  preceded  by  an  (automatically-inserted)  assertion  to  dynamically 
ensure  that  logger  is  of  the  appropriate  type  (shared (OFL)  OFL).  By  line  28,  logger 
only  has  shared  access  permission,  though  no  other  aliases  exist.  After  asserting  back 
full  access  permission,  logger  can  close  the  file  log. 

3.  FEATHERWEIGHT  TYPESTATE 

In  this  section  we  present  Featherweight  Typestate  (FT),  a  static  language  for 
typestate-oriented  programming.  FT  is  based  on  Featherweight  Java  (FJ)  [Igarashi 
et  al.  2001],  FT  is  the  first  formalization  of  a  nominal  typestate-oriented  program¬ 
ming  language,  with  support  for  representing  typestates  as  classes,  modular  typestate¬ 
checking  and  state  guarantees. 

3.1.  Syntax 

Figure  3  presents  FT’s  syntax.  Smallcaps  (e.g.  FieldNames)  indicates  syntactic  cate¬ 
gories,  italics  (e.g.  C)  indicates  metavariables,  and  sans  serif  (e.g.  Object)  indicates  par¬ 
ticular  elements  of  a  category.  An  overbar  (e.g.  A)  indicates  possibly  empty  sequences 
(e.g.  Ai, An ).  FT  assumes  a  number  of  primitive  notions,  such  as  identifiers  (includ¬ 
ing  this)  and  method,  field,  and  class  names  (including  Object).  An  FT  program  PG  is 
a  list  of  class  declarations  CL  paired  with  an  expression  e.  Class  definitions  are  stan¬ 
dard,  except  that  an  FT  class  does  not  have  an  explicit  constructor:  instead,  it  has  an 
implicit  constructor  that  assigns  an  initial  value  to  each  field.  Featherweight  Java,  for 
instance,  requires  an  explicit  constructor,  but  its  type  system  forces  the  same  behavior 
as  in  FT.  Fields  F  and  methods  M  are  mostly  standard.  Each  method  parameter  is 
annotated  with  its  input  and  output  types,  and  the  method  itself  carries  an  annotation 
(in  square  brackets)  for  the  receiver  object.  Like  FJ,  we  use  helper  functions  like  fields, 
method,  etc.,  whose  definitions  are  deferred  to  the  appendix. 

Types  in  FT  extend  the  Java  notion  of  class  names  as  types.  As  explained  in  Sec¬ 
tion  2,  the  type  of  an  FT  object  reference  has  two  components,  its  permission  and  its 
class  (or  state).  The  permission  can  be  broken  down  further  into  its  access  permission 
k  (described  previously  in  Figure  2)  and  state  guarantee  D.  We  write  these  object  ref¬ 
erence  types  in  the  form  k(D)  C.  Following  the  Java  tradition,  the  Void  type  classifies 
expressions  executed  purely  for  their  effects.  No  source-level  values  have  the  Void  type. 


5When  the  output  type  is  the  same  as  the  input  type,  we  omit  it  for  brevity;  a  practical  language  would 
provide  means  to  further  abbreviate  our  type  annotations. 

6A  practical  language  would  support  nullable  references,  but  for  simplicity  we  omit  this. 
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1  class  FileLogger  {  /*  Logging— related  data  and  methods  */  } 

2 

3  class  OpenFileLogger  :  FileLogger  { 

4  full(OF)  OF  file; 

5 

6  void  log(string  s) [shared(OFL)  OFL]  {...} 

7 

8  void  close() [full(FL)  OFL  »  full(FL)  FL]  { 

9  full(OF)  OF  fileT  =  (this. file  ;  =  :  new  0 F ( "/dev/null" ) ) ; 

10  assert<full(F)  0F>(fileT); 

n  fileT. close( ) ; 

12  this  <—  FileLogger( ) ; 

13  } 

14  } 

15 

16  //  Client  code 

17  void  staticLog(shared(OFL)  OFL  logger)  { 

18  logger. log( "in  staticLog"); 

19  } 

20  Dyn  dynamicLog(Dyn  logger)  {  logger. log("in  dynamicLog" ) ;  } 

21 

22  full(OF)  OF  fileO  =  new  0F(...); 

23  full(OFL)  OFL  logger  =  new  OFL(fileO); 

24 

25  hold[logger:shared(OFL)  0FL]{  dynamicLog (logger) ;  } 

26  staticLog(logger) ; 

27 

28  assert<full(FL)  0FL>(logger) ; 

29  logger. close( ) ; 

Listing  1:  Sample  Typestate-Oriented  Code. 


To  simplify  the  description  of  the  type  system,  expressions  in  FT  are  restricted  to 
A-normal  form  [Sabry  and  Felleisen  1993],  so  let  expressions  explicitly  sequence  all 
complex  operations  (we  write  ex;  as  shorthand  for  the  standard  encoding). 

Apart  from  method  invocation,  field  reference  and  object  creation  (all  standard),  FT 
includes  the  update  operation  x0  <—  C(xi),  which  lets  programs  directly  express  types- 
tate  change.  It  replaces  the  object  referred  to  by  x0  with  a  new  object  of  class  C,  which 
may  not  be  the  same  as  xq’s  current  class.  Also  non-standard  is  the  swapping  assign¬ 
ment  x0.f  :=:  xx.  It  assigns  the  value  of  x\  to  the  field  /  of  object  x0  and  returns  the 
old  value  as  its  result.  Section  3.3  explains  why  this  is  needed. 

The  assert  operation  changes  the  static  type  of  an  object  reference.  Asserts  are  sim¬ 
ilar  to  casts  in  that  an  assert  up  the  subclass  hierarchy  succeeds  immediately,  while 
an  assert  down  the  class  hierarchy  requires  a  runtime  check.  Assertions  are  strictly 
more  powerful  than  casts:  they  change  the  type  of  an  existing  reference,  whereas  casts 
produce  a  new  reference  with  a  different  type.  In  fact,  a  type  cast  (T)  x  can  be  encoded 
using  class  assertions: 


a  lety  :  T0  =  x 

(T)  x  =  in  let  z  :  Void  =  assert(T)(y) 

in  y 
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Fig.  3:  Featherweight  Typestate:  Syntax 


where  y  and  z  are  fresh,  and  the  type  T0  depends  on  how  much  permissions  are  to  be 
taken  from  x.  The  assert  operation  of  FT  cannot  change  the  permission  of  a  variable, 
but  the  run-time  permission  tracking  introduced  in  GFT  will  allow  us  to  add  support 
for  permission-changing  assertions  there. 

The  hold  expression  hold[x  :  T ]  ( e )  captures  the  amount  of  x’s  permissions  denoted 
by  T  for  the  duration  of  the  computation  e.  When  e  completes,  these  permissions  are 
merged  back  into  x. 

3.2.  Managing  Permissions 

Before  we  present  FT’s  typing  judgments,  we  must  explain  how  permissions  are 
treated.  Permissions  to  an  object  are  a  resource  that  is  split  among  the  variables  and 
fields  that  reference  it.  Figure  4  presents  several  auxiliary  judgments  that  specify  how 
permissions  may  be  safely  split,  and  how  they  relate  to  typing. 

First,  access  permission  splitting  ki  k2/ks  describes  how  given  a  k\  access  permis¬ 
sion,  k2  can  be  acquired,  leaving  behind  fc3  as  the  residual.  When  we  are  only  concerned 
that  k2  can  be  split  from  k  \  (i.e.  the  residual  access  permission  is  irrelevant),  we  write 
fci  ^  k2.  For  instance,  given  any  access  permission  k,  full  ^  k  and  k  ^  k. 

Permissions  partially  determine  what  operations  are  possible,  as  well  as  when  an 
object  can  be  safely  bound  to  an  identifier.  The  restrictions  on  permissions  are  for¬ 
malized  as  a  partial  order,  analogous  to  subtyping.  The  notation  Pi  <■■  P2  says  that 
Pi  is  a  subpermission  of  P2,  which  means  that  a  reference  with  i\  permission  may 
be  used  wherever  an  object  reference  with  P2  permission  is  needed.  As  expected,  the 
subpermission  relation  is  reflexive,  transitive,  and  anti-symmetric.  The  first  subper¬ 
mission  rule  says  that  splitting  an  access  permission  produces  a  lesser  (or  identical) 
permission.  The  subpermission  rules  for  pure  and  full  access  permissions  respectively 
capture  how  state  guarantees  affect  the  strength  of  permissions.  Pure  access  permis¬ 
sions  covary  with  their  state  guarantee  because  a  pure  reference  with  a  superclass 
state  guarantee  assumes  less  reading  capability.  Full  access  permissions  contravary 
with  their  state  guarantee  because  a  full  reference  with  a  subclass  state  guarantee 
assumes  less  writing  capability  (i.e.  it  can  update  to  fewer  possible  states).  Although 
full  access  permissions  also  allow  reads,  those  reads  can  only  see  writes  through  the 
full  reference  itself;  therefore  contravariance  is  enough  and  we  do  not  have  to  enforce 
invariance.  The  last  rule  ensures  that  subpermissions  are  transitive. 
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Fig.  4:  Permission  and  Type  Management  Relations 

Permission  splitting  extends  access  permission  splitting  to  account  for  state  guar¬ 
antees.  First,  if  ki(Di)  <:  /;:2 {D2),  then  the  latter  can  safely  be  split  from  the  former. 
The  remaining  task  then  is  to  determine  the  proper  residual  permission  k3(D3).  The 
residual  access  permission  k3  comes  directly  from  access  permission  splitting.  For  the 
residual  state  guarantee,  observe  that  ki(D3)  <:  fc2 ( D2 )  implies  that  I)\  and  D2  are  re¬ 
lated  by  subclassing.  By  considering  the  possible  cases  of  permission  splitting,  we  find 
that  the  state  guarantee  should  be  whichever  of  D3  and  D2  is  subclass  of  the  other: 
this  is  necessary  if  k3  is  a  write  access,  and  ideal  if  k3  is  pure.  We  denote  this  as  the 
greatest  lower  bound  of  D\  and  D2  in  the  subclass  hierarchy  D\  A  D>,  an  operation 
that  we  use  (along  with  greatest  lower-bound  permission  P3  A  p2)  several  times  in  the 
language  formalization. 

Permission  splitting  in  turn  extends  to  type  splitting  T  T/T,  taking  subclasses 
into  account  for  object  references;  the  Void  type  can  be  arbitrarily  split.  Type  splitting 
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has  a  special  case  called  the  maximum  residual,  the  most  permissions  that  can  be  split 
without  changing  the  original  type.  Type  splitting  determines  the  notion  of  subtyping 
T  <:  T  used  in  FT.  As  with  access  permission  splitting,  we  write  Pi  P2  or  Tj  ^  T  to 
express  that  P2  or  T2  can  be  split  from  Pi  or  Tj  respectively. 

Converse  to  type  splitting  is  type  merging,  denoted  T/T  ^  T.  The  type  merging  re¬ 
lation  describes  how  two  separate  permissions  to  the  same  underlying  object  may  be 
combined. 

The  compatible  permissions  relation  Pi  <-»  P2  says  that  two  distinct  references  to  the 
same  object,  one  with  permissions  Pi  and  the  other  with  P2  can  soundly  coexist  at  run¬ 
time.  For  instance,  shared((7)  <->  shared(C),  and  full(C')  <->  pure(Object).  On  the  other 
hand,  full(C')  <«■  full(C)  because  if  one  of  these  references  updated  its  state  guarantee 
(further  down  the  subclass  hierarchy),  then  the  other  reference  could  violate  it  during 
a  state  change  operation.  The  compatible  permission  relation  is  used  to  define  the  re¬ 
lation  P  compatible :  that  the  outstanding  permissions  P  of  references  to  a  particular 
object  can  all  coexist.  These  concepts  are  critical  for  showing  that  well-typed  programs 
remain  in  a  consistent  state  as  they  run. 

Finally,  we  defer  the  discussion  of  type  demotion  to  the  end  of  Section  3.3. 

3.3.  Static  Semantics 

Armed  with  the  permission  management  relations,  we  now  discuss  the  most  salient 
feature  of  FT’s  static  semantics:  flow-sensitive  typing. 

As  with  FJ,  the  FT  type  system  relies  upon  type  contexts.  Whereas  T  is  the  standard 
metavariable  for  type  contexts,  we  use  a  different  metavariable  A  to  emphasize  that 
the  typing  contexts  are  not  merely  lexical.  In  our  notation,  A,  x  :  T  specifies  a  context 
A'  that  includes  all  of  the  bindings  in  A  plus  the  binding  x  :  T,  which  requires  that  A 
contains  no  entry  for  x.  In  FT’s  type  system,  the  types  of  identifiers  are  flow-sensitive 
in  the  sense  that  they  vary  over  the  course  of  a  program.  In  part  this  reflects  how  the 
permissions  to  a  particular  object  may  be  partitioned  and  shared  between  references 
as  computation  proceeds,  but  it  also  reflects  how  update  and  assert  operations  may 
change  the  class  of  an  object  during  execution. 

The  FT  typing  judgment  is  a  quaternary  relation  of  the  form  Ai  b  e  :  T  b  A2,  which 
means  “given  the  typing  assumptions  Ai,  the  expression  e  can  be  assigned  the  type 
T  and  doing  so  produces  typing  assumptions  A2  as  its  output.”  The  assumptions  in 
question  are  the  types  of  each  reference.  Threading  typing  contexts  through  the  typing 
judgment  captures  the  flow-sensitivity  of  type  assumptions. 

Typing  rules.  Figure  5  presents  the  typing  rules  for  FT  expressions  (all  prefixed  with 
“ST”:  S  for  “static  typing”  and  T  for  “typing”). 

The  (STvar)  typing  rule,  for  variable  references,  demonstrates  flow-sensitive  typing 
immediately.  If  the  type  context  binds  a  variable  1  to  a  type  7j ,  and  that  variable  is 
referenced  at  type  T2,  then  the  output  type  context  resets  the  type  assumption  for  x 
according  to  the  type  splitting  relation.  Observe  that  the  (STvar)  rule  implies  that  in 
general  a  variable  reference  can  be  given  many  possible  types: 

LEMMA  3.1.  If  A  b  X  :  Tj  H  A'  and  T\  <:  T2  Then  A  b  x  :  T2  b  A"  for  some  A". 

This  is  similar  to  the  standard  subsumption  rule  for  object-oriented  languages,  but 
changing  the  type  from  '1\  to  T2  also  changes  the  output  context. 

The  (STlet)  rule  reflects  the  standard  value-binding  behavior  for  let,  but  it  also  se¬ 
quences  permission-consuming  operations.  After  typing  the  expression  bound  to  x,  the 
new  typing  context  is  updated  with  a  type  assumption  for  x,  which  is  used  to  type  the 
body  of  the  let.  To  preserve  lexical  scoping,  x  (and  its  associated  permission)  is  removed 
from  the  output  context. 
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where 

A  b  x  :  T  n  A'  =  A  =  Ao  h  xo  :  To  H  Ai;  Ai  b  Xi  :  Ti  H  A2;  •  ■  ■  An  b  x„  :  Tn  H  An+i  =  A' 

Fig.  5:  Featherweight  Typestate:  Expression  Typing  Rules 


The  (STnew)  rule,  for  creating  a  new  object,  is  analogous  to  the  equivalent  Java  rule. 
The  prominent  difference  is  that  in  FT  a  new  object  also  has  permissions  associated 
with  it.  The  reference  to  a  new  object  is  given  full  (Object)  permissions  because  it  is 
unique,  so  it  can  update  the  object  arbitrarily  without  concern  about  aliases.  This  rule 
relies  on  an  auxiliary  judgment  that  captures  the  idea  of  a  well-typed  constructor  call: 
the  arguments  to  the  constructor  are  iteratively  checked  against  the  class  fields  and 
the  typing  context  is  iteratively  updated  accordingly.  This  means  that  a  variable  may 
be  given  for  more  than  one  argument  to  the  constructor,  but  because  of  flow-sensitive 
typing,  it  may  be  typed  differently  each  time. 

The  (STassert)  rule  reflects  how  the  assert  operation  assert(T)(./:)  changes  class  type 
information  of  the  reference  x.  Though  FT  types  consist  of  more  than  the  object’s  class, 
this  operation  can  only  affect  the  class  part  of  an  object’s  type:  the  permission  must 
stay  the  same.  The  assert  operation  could  safely  decrease  permissions  to  an  object,  but 
it  would  add  no  expressiveness  to  the  language. 

The  (SThold)  rule  reflects  how  the  hold  expression  acquires  permissions  to  an  object 
for  the  dynamic  extent  of  its  subordinate  expression.  Once  that  expression  completes, 
the  held  permissions  are  returned  to  the  reference  from  which  they  were  acquired.  It 
types  the  subexpression  e  after  splitting  T2  from  variable  x.  The  resulting  type  of  x  is 
the  merge  of  the  demotion  of  T>  (the  type  being  being  held)  and  1  j ,  the  resulting  output 
type  of  x  after  evaluation  of  e. 
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Class  update.  The  (STupdate)  rule  type  checks  FT’s  novel  update  operation, 
x\  <—  62(^2),  which  replaces  the  receiving  object  referenced  by  x\  with  C-FWi)-  This 
operation  is  only  possible  if  the  reference  to  the  receiving  object  has  shared  or  full  ac¬ 
cess  permissions  to  the  underlying  object.  The  possible  target  states  of  an  object  are 
implicitly  constrained  by  the  state  guarantee  that  the  object  has  after  the  arguments 
to  the  constructor  have  been  typed,  since  k(D)  C  must  be  a  well-formed  type.  This  en¬ 
sures  that  the  outstanding  references  to  the  updated  object  (including  possibly  its  own 
fields)  all  have  a  consistent  view  of  the  object.  The  type  of  the  update  operation  is  Void 
since  it  is  performed  solely  for  its  effect  on  the  heap.  The  type  of  the  updated  object  in 
the  output  context  reflects  its  new  class. 

Type  demotion.  Update  operations  can  alter  the  state  of  any  number  of  variable  ref¬ 
erences.  To  retain  soundness  in  the  face  of  these  operations,  it  is  sometimes  necessary 
to  discard  previously  known  information  in  case  it  has  been  invalidated.  In  these  cases, 
an  object  reference’s  class  must  revert  to  its  state  guarantee,  which  is  a  trusted  state 
after  an  update.  The  type  demotion  function  T{  (Figure  4)  expresses  this  restricting 
of  assumptions.  Note  that  full  references  need  not  be  demoted  since  no  other  reference 
could  have  changed  their  states.  We  write  Aj.  for  the  compatible  extension  of  demotion 
to  typing  contexts. 

The  (STupdate)  rule  necessarily  demotes  types:  type  assumptions  from  the  input 
context  are  demoted  in  the  output  context  to  ensure  that  any  aliases  to  the  updated 
object  retain  a  conservative  approximation  of  the  object’s  current  class. 

Note  that  type  demotion  does  not  imply  any  runtime  overhead:  it  is  a  purely  static 
process.  Furthermore,  types  of  class  fields  have  the  restriction  that  they  must  be  in¬ 
variant  under  demotion  (i.e.  TJ.  =  T).  This  means  that  a  field  with  shared  or  pure  access 
permission  has  the  same  class  type  as  its  state  guarantee.  Since  the  types  of  fields  do 
not  change  as  a  program  runs,  they  must  not  be  invalidated  by  update  operations. 
This  restriction  ensures  that  field  types  remain  compatible  with  other  aliases  to  their 
objects.  As  a  result  only  local  variable  types  need  ever  be  demoted. 

The  classes  of  variables  in  A2  are  demoted  to  their  state  guarantees  since  state 
change  may  have  invalidated  those  stronger  assumptions.  Only  one  object  is  updated 
by  this  operation,  but  it  may  affect  any  number  of  outstanding  references. 

Field  Operations.  As  was  mentioned  in  Section  3.1,  two  operations  operate  directly 
on  an  object  field:  field  reference  and  swapping  assignment.  Field  reference  (STfield) 
does  not  relinquish  any  of  the  permissions  held  by  the  field,  so  the  result  type  is  deter¬ 
mined  by  taking  the  maximal  residual  T'2  of  the  field  type  T2.  This  operation  does  not 
affect  the  permissions  of  the  object  reference  used  to  access  the  field. 

Swap  operations  (STswap)  cause  an  object  to  relinquish  all  permissions  to  a  field 
and  replace  it  with  a  new  reference.  The  swap  expression  has  two  purposes.  The  first 
is  to  reassign  a  field  value  in  the  heap.  The  second  is  to  return  the  old  field  value  as  the 
result  of  the  expression.  If  a  field  has  shared  or  pure  access  permissions  to  an  object, 
then  field  reference  can  yield  the  same  amount  of  permission;  however,  if  a  field  has 
full  access  permission  to  an  object,  only  swapping  can  yield  that  full  access  permission. 

Method  Invocation.  The  (STinvoke)  rule  describes  how  method  invocations  are  type 
checked.  When  invoking  a  method,  first  the  method  declaration  is  looked  up  based  on 
the  type  of  the  receiver.  Next,  both  the  receiver  and  the  arguments  are  checked  for 
compatibility.  The  resulting  type  of  the  expression  is,  as  usual,  specified  by  the  method 
declaration.  The  outgoing  context  demotes  the  references  in  A.  This  is  necessary  to 
keep  type  checking  modular,  since  the  method  call  may  perform  typestate  update  op¬ 
erations.  The  outgoing  types  for  the  receiver  and  the  arguments  are,  however,  listed  in 
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Md ok  in  C 


Well-typed  Method  Declaration 


class  C  extends  £>{•■■} 

mdecl(D,m)  undefined 


class  C  extends  £>{■■•} 

mdecl(D,  m)  =  Tr  m(Ti  »  T')[Pt  E  »  Tt'] 


Tr  m(Ti  »  T')[Pt  C  »  Tt]  ok  in  C  Tr  m{Ti  »  T[)[Pt  C  »  Tt']  ok  in  C 

M  ok  in  C  Well-typed  Method 


Tr  m{Ti  »  T")[Pt  Ct  »  T"]  ok  in  Ct 


this  :  Pt  Ct,x  :Tih  e:Tr 
T[  <:  T" 


this  :  Tt,  x  :  T[ 
T’  <:  T" 


Tr  m(Ti  »  T"  x)  [Pt  Ct  »  Tt]  {  return  e;  }  ok  in  Ct 


CL  ok  Well-typed  Class 


Co  S:  Object  k(D)  E |=  k(D)  E  M  ok  in  C0 


PG  ok  Well-typed  Program 

CL  ok  •  b  e  :  T  H  ■ 


class  Co  extends  Ci  {  k(D)  E  f-  M  }  ok  (CL,  e)  ok 

Fig.  6:  FT  Program  Typing  Rules 


the  method’s  declaration,  and  as  such  are  available  to  the  program  when  the  method 
returns. 

Note  that  in  several  other  expressions  (new,  for  example),  permissions  to  certain 
variables  (arguments  to  the  constructor)  are  implicitly  split,  and  residual  permissions 
are  left  over  for  typing  the  remainder  of  the  program.  Method  invocation  is  different. 
To  keep  FT’s  design  simple,  the  method  invocation  rule  checks  that  method  arguments 
(including  the  receiver)  have  enough  permission  to  type  the  method  call,  and  discards 
any  residual  permissions.  Also,  the  structure  of  (STinvoke)  requires  all  method  argu¬ 
ments  to  be  unique,  e.g.,  x.m(y ,  y)  is  untypeable  (See  Section  3.7). 

Typing  Programs.  Recall  that  an  FT  program  is  a  pair  of  a  class  table  and  an  ex¬ 
pression.  To  formalize  the  notion  of  a  well-typed  program,  we  introduce  a  few  more 
judgments  (Figure  6). 

First  we  consider  the  interface  or  declaration  of  a  method: 

Md  ::=  T  m(T  »  T)  [T  »  T] 

The  method  declaration  judgment  Md  ok  in  C  checks  that  the  interface  specification 
for  a  method  is  compatible  with  a  particular  class,  which  holds  if  the  method  is  alto¬ 
gether  new,  or  a  proper  override  of  a  superclass  method.  This  is  used  by  the  method 
typing  judgment  M  ok  in  C,  which  checks  that  a  method  M  is  well-typed  if  it  is  de¬ 
fined  as  part  of  class  C.  To  type  the  body  of  the  method,  the  rule  assumes  the  input 
types  from  the  method  declaration.  On  completion  of  typing  the  method,  the  argu¬ 
ments  and  this  are  checked  against  the  method’s  output  specification.  This  typing  rule 
allows  this  and  the  arguments  x  to  be  subtypes  of  the  output  types  specified  by  the 
declaration.  The  method  is  well-typed  so  long  as  enough  permissions  remain  for  these 
variables  to  match  the  declared  output  specification.  If  the  type  system  required  the 
output  context  A0  to  exactly  match  the  output  specification,  then  the  language  would 
need  more  mechanisms  (such  as  an  explicit  subsumption  rule). 

For  a  class  definition  to  be  well-typed,  all  of  its  fields  must  have  object  reference 
types,  all  of  its  methods  must  be  well-typed,  and  its  superclass  hierarchy  must  lead 
to  Object.  This  implies  that  all  intermediate  superclasses  are  defined  and  that  every 
chain  of  superclasses  ends  at  Object,  i.e.  there  are  no  inheritance  cycles.  Also,  as  ex- 
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plained  above,  we  require  that  the  permissions  associated  with  field  types  be  invariant 
under  demotion. 

Finally,  a  program  is  well-typed  if  its  class  table  and  main  expression  are  well-typed 
in  turn. 


3.4.  Dynamic  Semantics 

The  runtime  semantics  of  the  language  add  some  new  syntactic  notions.  In  particu¬ 
lar,  FT  is  a  stateful  language,  so  most  values  in  the  language  are  references  to  heap- 
allocated  objects. 


o 

l 

v 

C(o) 

e 


s 

v 

P 

P 

E 


£ 

E 

£ 

£ 


£ 

£ 


ObjectRefs 

IndirectRefs 

Values 

Objects 

s  |  v  |  let  x  :  T  =  e  in  e  |  new  C(s)  |  s.f 
s.m(s )  J  s.f  :=:  s  \  s  <—  C(s)  |  assert <T)(s) 
merged  :  T/l](e ) 

x  1 1 

void  |  o 

ObjectRefs  Objects 
IndirectRefs  —  Values 
□  |  let  x  =  E  in  e  |  merge[Z  :  T/l\{ E) 


(expressions) 


(simple  expressions) 
(values) 

(stores) 

(environments) 
(evaluation  contexts) 


Ultimately,  expressions  in  the  language  evaluate  to  values,  i.e.  void  or  an  object  refer¬ 
ence  o.  Since  the  language  is  imperative,  the  value  void  is  used  as  the  result  of  opera¬ 
tions  that  are  only  interesting  for  their  side-effects.  In  other  object-oriented  languages, 
a  void  object  is  unnecessary:  imperative  operations  can  return  some  arbitrary  object 
reference.  However,  FT  must  explicitly  consider  how  permissions  to  an  object  are  dis¬ 
tributed,  so  providing  a  void  object  lets  us  clearly  indicate  when  no  permissions  to  any 
object  are  returned. 

The  merge  expression  is  a  technical  device  that  models  how  held  permissions  are 
treated  dynamically.  It  tracks  held  permissions  at  runtime  and  ultimately  merges 
those  held  permissions  back  into  their  associated  indirect  reference.  This  expression  is 
purely  a  tool  for  proving  type  safety. 

To  connect  object  references  to  objects,  we  use  stores  /i,  which  abstract  the  runtime 
heap  of  a  program.  Stores  are  represented  as  partial  functions  from  object  references  o 
to  objects  C(o).  A  well-formedness  condition  is  imposed  on  stores:  only  object  references 
o  in  the  domain  of  a  store  can  occur  in  its  range. 

In  addition  to  the  traditional  heap,  the  dynamic  semantics  uses  a  second  heap,  which 
we  call  the  environment,  that  mediates  between  variable  references  and  the  object 
store.  The  environment  serves  a  purely  formal  purpose:  it  supports  the  proof  of  type 
safety  by  keeping  precise  track  of  the  outstanding  permissions  associated  with  differ¬ 
ent  references  to  objects  at  runtime.  In  the  source  language,  two  variables  could  refer 
to  the  same  object  in  the  store,  but  each  can  have  different  permissions  to  that  object. 
The  environment  tracks  these  differences  at  runtime.  It  maps  indirect  references  l  to 
values  v.  Two  indirect  references  can  point  to  the  same  object,  but  the  permissions 
associated  with  the  two  indirect  references  are  kept  separate.  The  runtime  language 
therefore  adds  a  notion  of  simple  expressions  s,  which  include  true  variables  x  and 
indirect  references  l,  and  may  be  used  in  the  runtime  language  everywhere  that  vari¬ 
ables  can  be  used  in  the  programmer-visible  language  (except,  of  course,  variable  defi¬ 
nition).  The  environment  is  not  needed  in  a  practical  implementation  of  the  language. 
As  we  show  later  (Section  3.6),  well-typed  programs  can  be  safely  run  on  a  traditional 
single-heap  machine  where  object  references  are  simple  expressions. 
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/  /  / 
/x,  p,  e  — >  p  ,  p  ,  e 


(SElookup)- 


<  ->•  M,P,P( 0 
(SElet) 


^  °  ^  rfom(/x) 

(SEnew) - _  - - 

P,  p ,  new  C(Z)  p [n  >->•  C(p(0)]>  P,  o 

l  dom(p) 


(SEupdate)- 


p,  p,  let  x  :  T  =  r  in  e  — >  p,  p[Z  >->  w],  [Z /sc] e 

p,  P,  (It  «-  C(0)  -  p[p(zt)  ~  C(p(0)],p,  void 
p(p(0)  =  C(o)  /ZeZo?5(C')  =  T? 


(SEfield) 


(SEswap)- 


P,pfi-fi  -*•  P,P,  o* 

p(p(Zi))  =  C(-  ■  -Oi  ■  ■  ■)  fields (C )  =  T  / 

P,P,h-fi  :=:  h  ->  p[p(Zi)  C(-  •  -p(l2)  ■  •  -)]>P»°i 

p(p(0)  =  C7(-  -  -  )  C  <:  D 


(SEinvoke)  - 


(SEassert)- 

p,  p.  assert(P  D)(l)  — >  p,  p,  void 

p(p(0)  =  g(---) 

method(m,  C )  =  Tr  m(T  »  T'  x)  \Tt  »  Tt']  {  return  e;  } 


(SEcongr)- 


(SEhold)- 


p,p,  — >  p,  p,  [Z'/rc]  [Z/this]e 

p,p,  ei  ->  p',p',e i 


p,  p,  let  x  :  T  =  ei  in  e2  — >  //,  p',  let  x  :  T  =  ej  in  e2 


l'  $  dom(p) 


p, p,  hold[Z  :  T](e)  -►  p, p[Z'  >-»  p(Z)],  merge[Z :  (T|)/Z'](e) 

(SEmcongr)- 


p,  p,e  —>  p' ,  p\  e' 


p,p,  merged  :  T/Z2](e)  -►  p',p',  merge [Zi  :  T/Z2](e') 

(SEmerge) - - - - — — — - 

p,p,  merge[Zi  :  T/h]{v)  -»  p,p,x 

Fig.  7:  FT  Dynamic  Semantics 


To  state  and  prove  our  notion  of  type  safety,  we  use  a  notion  of  evaluation  contexts  E. 
Evaluation  contexts  are  expressions  with  holes,  notation  □,  in  them.  An  expression  can 
be  plugged  into  the  hole  to  produce  a  program.  Following  the  presentation  of  Feather¬ 
weight  Java  by  Pierce  [2002],  we  use  evaluation  contexts  to  capture  the  possibility  of 
a  program  getting  stuck  at  a  bad  assertion. 

The  dynamic  semantics  of  FT  is  formalized  as  a  structural  operational  semantics  de¬ 
fined  over  store/environment/expression  triples.  Figure  7  presents  the  rules  (prefixed 
by  “SE”:  “S”  for  static  typing,  “E”  for  evaluation). 

The  (SElookup)  rule  dereferences  an  indirect  reference  to  get  the  underlying  value. 
The  (SEnew)  rule  creates  a  new  object  based  on  the  constructor  expression  given.  The 
arguments  to  the  constructor  are  dereferenced  so  that  the  objects  in  the  heap  contain 
object  references.  The  (SElet)  rule  handles  a  variable  binding  by  allocating  a  new  in¬ 
direct  reference,  associating  the  object  reference  in  question  to  it  in  the  environment 
and  substituting  the  fresh  reference  into  the  body  of  the  let  expression.  The  (SEupdate) 
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rule  replaces  a  binding  in  the  store  with  a  newly-constructed  object.  The  (SEfield)  rule 
looks  up  the  field  of  an  object  in  the  heap  and  returns  the  corresponding  object  refer¬ 
ence.  The  (SEswap)  rule  swaps  the  field  of  an  object  with  a  new  object  reference  and 
returns  the  old  one.  The  (SEassert)  rule  checks  that  a  reference  points  to  an  object 
with  a  type  compatible  with  the  assertion.  If  the  assertion  succeeds,  the  program  re¬ 
turns  a  void  value;  if  not,  the  program  gets  stuck.  The  (SEinvoke)  rule  substitutes  the 
arguments  to  the  method  invocation  into  the  method  body  and  continues  executing. 
The  (SEcongr)  rule  ensures  that  the  bound  expression  in  a  let  is  computed  before  the 
body  of  the  let.  The  (SEhold)  rule  initiates  the  bookkeeping  process  of  holding  on  to 
permissions  while  a  subexpression  executes.  It  uses  a  new  indirect  reference  l1  to  hold 
its  permissions.  The  (SEmcongr)  rule  allows  the  expression  inside  of  the  merge  expres¬ 
sion  to  execute.  The  (SEmerge)  expression  removes  the  bookkeeping  information  once 
the  relevant  subexpression  has  evaluated  to  a  final  value. 


3.5.  Type  Safety 

In  order  to  establish  type  safety,  the  type  system  must  be  extended  to  account  for 
runtime  phenomena.  First,  we  must  type  the  void  value. 


(STvoid) 


A  b  void  :  Void  H  A 


To  type  runtime  programs,  type  contexts  must  be  extended  to  account  for  runtime 
references. 


b  e  x  \  l  \  o  (context  bindings) 

A  ::=  b  :  T  (linear  type  contexts) 


Since  runtime  expressions  have  no  free  variables  but  may  now  contain  indirect  refer¬ 
ences  l  and  object  references  o,  a  typing  context  may  only  have  entries  of  the  form  l  :  T 
and  o  :  T.  As  such,  the  type  rules  must  account  for  references  in  a  runtime  program, 
e.g.: 


(STvar) 


A,  s 


Ti  =>  T2/T3 _ 

T\  b  s  :  X2  — I  A,  s  :  X3 


(STobj) 


A,o:Tbo:TbA 


Since  variables  are  replaced  by  indirect  references  at  runtime,  they  should  be  typed 
similarly.  On  the  other  hand,  an  object  reference  may  only  appear  once  in  a  program,  as 
the  result  of  a  variable  reference,  which  will  either  be  bound  to  a  variable  immediately, 
or  returned  as  the  final  program  result.  As  such,  it  is  safe  to  consume  it  entirely. 

Other  references  to  variables  in  FT’s  type  system  should  now  consider  simple  ex¬ 
pressions  (variables  or  indirect  references)  rather  than  just  variables,  for  example: 


fields(C)  =  T  f  A  b  s  :T  H  A' 

(STnew) - 

A  b  new  C(  s  )  :  full(Object)  C  b  A' 

Furthermore,  context  demotion  Af  must  be  extended  to  the  reference  entries  in  a  con¬ 
text. 

In  addition,  we  require  a  typing  rule  for  the  runtime  merge  expression: 

er  Ti=Tl  A,  (2  :T2  b  e  :  r  b  Ax ,  i2  '.TL,  Tx/T^  T3 
A,  A  :  T\ ,  I2  :  T2  b  merge[A  :  Xi/Z2](e)  :  T  H  A1J2  ■  T'i 

The  merge  expression  owns  the  indirect  reference  l\,  which  it  uses  to  store  the  permis¬ 
sions  that  it  is  holding  to  later  merge  back  into  1-2-  Thus  the  outgoing  permissions  of  l> 
combine  the  output  of  the  computation  e  with  the  held  permissions. 
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Helper  Functions 

ref  Types  (p,  A,  p,  o) 
fieldTypes(p ,  o) 
envTypes(A,  p,  o ) 
ctxTypes( A,  o) 


=  fieldTypes(p,  o)  ++  envTypes( A,  p,  o)  ++  ctxTypes( A,  o) 

=  ++  [Ti  |  p(o')  =  CM,  fields(C)  =  T?,  and  o"  =  o] 

o'  Edom(ij) 

=  ++  [T  j  p(0  =  o  and  (l  :T)  e  A] 

l€dom(p ) 

=  [T  |  o  :  T  €  A] 


p,  A,  p  ok 

p,  A,  p  \-  o  ok 

Reference  Consistency 

p(o)  =  C(o')  |  o'  |  =  |/ieWs(C) 

refTypes(p,  A,  p,  o)  =  fc(-E)  D 
C  <\  D  k(E)  compatible 
p,  A,  p  \-  o  ok 


dom(A)  cz  dom(p)  u  dom(p) 

{l  \  (l  ■■  Void)  s  A  }  c:  { l  |  p{l)  =  void  } 
{l\{l:  k(D)  C)  £  A}  cz  {l  j  p(l)  =  0} 
p,  A,  p  \-  dom(p)  ok 
p,  A,pok 


phe  me  Merge  Consistency 


VE.  e  =  E[merge[ii  :  Ti//2](e')]  =>  p{h)  =  0  =  p(l2) 
p  |-e  me 

Fig.  8:  FT  Permission  Consistency  Relations 


To  prove  type  safety,  we  must  account  for  the  outstanding  permissions  associated 
with  references  to  each  object  o  and  make  sure  that  they  are  mutually  consistent.  To 
achieve  this,  we  appeal  to  some  helpers,  presented  in  Figure  8.  The  fieldTypes  function 
takes  a  heap  and  an  object  reference  in  the  domain  of  the  heap  and  produces  a  list  of 
the  type  declarations  for  every  field  reference  to  that  object.  This  function  disregards 
object  references  that  are  not  bound  to  some  field  of  some  object.  The  envTypes  func¬ 
tion  performs  the  analogous  operation  for  the  indirect  references  in  an  environment 
that  have  bindings  in  the  context.  This  function  disregards  indirect  references  in  the 
environment  that  have  no  typing  in  the  context.  The  ctxTypes  function  does  the  same 
for  object  references  that  occur  in  a  type  context.  The  refTypes  function  takes  a  heap, 
context,  environment,  and  object  and  yields  the  list  of  type  declarations  for  outstand¬ 
ing  heap,  environment,  and  context  references.  These  definitions  use  square  brackets 
to  express  list  comprehensions,  and  ++  to  express  list  concatenation. 

Using  the  refTypes  function  and  permission  compatibility,  we  can  define  a  notion 
of  reference  consistency  that  verifies  the  mutual  compatibility  of  the  types  of  all  out¬ 
standing  references  to  some  object  in  the  heap.  A  consistent  object  reference  points  to 
an  object  that  has  the  proper  number  of  fields,  and  all  references  to  it  are  well-formed, 
assume  a  plausible  class,  are  mutually  compatible,  and  are  tracked  in  the  store. 

Reference  consistency  is  used  in  turn  to  define  global  consistency,  which  establishes 
the  mutual  compatibility  of  a  store-environment-context  triple.  Global  consistency  im¬ 
plies  that  every  object  reference  in  the  store  satisfies  reference  consistency,  that  every 
reference  in  the  type  context  is  accounted  for  in  the  store  and  environment,  and  that 
Void  and  object-typed  indirect  references  ultimately  point  to  void  values  and  object  ref¬ 
erences  respectively.  Note  that  global  consistency  and  permission  tracking  take  into 
account  even  objects  that  are  no  longer  reachable  in  the  program. 

To  prove  that  preservation  holds,  we  require  an  additional  notion  of  consistency, 
called  merge  consistency,  to  ensure  that  only  indirect  references  to  the  same  underlying 
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object  are  ever  merged.  This  judgment  helps  us  guarantee  that  permissions  produced 
at  runtime  by  hold  expressions  are  only  combined  in  sound  ways. 

These  concepts  contribute  to  the  statement  (and  proof)  of  type  safety. 

THEOREM  3.2  (PROGRESS).  If  e  is  a  closed,  expression  and  A  1 —  e  :  T  -\  A',  then 
either  e  is  a  value  or  for  any  store  p  and  environment  p  such  that  p,  A,  p  ok,  either 
p,  p,  e  — >  pi ,  p' ,  e'  for  some  store  p',  environment  p',  and  expression  e',  or  e  is  stuck  at  a 
bad  assert,  i.e.,  e  =  E[assert(D)(^)]  where  p(p(l))  =  C(-  ■  ■ ),  and  C  <f:  D. 

PROOF.  By  induction  on  the  derivation  of  A  b  e  :  T  H  A'.  □ 

To  facilitate  our  proof  of  type  preservation,  we  define  and  establish  an  invariant  of 
program  evaluation.  Our  semantics  has  many  rules  that  evaluate  to  an  object  refer¬ 
ence,  but  the  reference  is  either  returned  as  the  final  result  of  the  program,  or  imme¬ 
diately  bound  to  an  identifier  (as  in  let  x  :  T  =  o  in  e).  Furthermore,  at  most  one  object 
reference  appears  in  a  program  at  any  point  of  execution.  We  capture  these  invariants 
as  follows: 

Definition  3.3.  An  expression  e  is  in  head  reference  form,  notation  hdref(e )  iff  either 

(1)  e  contains  no  object  references  o;  or 

(2)  e  =  E[o]  for  some  E,  o  and  E  contains  no  object  references. 

When  a  program  is  in  head  reference  form  and  takes  a  step  that  produces  or  consumes 
an  object  reference,  we  can  easily  characterize  a  type  context  that  establishes  preser¬ 
vation. 

Finally,  we  establish  a  relationship  between  type  contexts  that  helps  us  show  that 
evaluating  a  subterm  retains  enough  output  permissions  to  continue  executing  the 
rest  of  the  program.  This  is  needed  in  particular  to  support  method  invocations,  since 
the  permissions  resulting  from  evaluating  a  method  body  may  be  be  stronger  than  the 
method  interface  declares. 

Definition  3.4.  A  context  A  is  stronger  than  a  context  A',  notation  A  <  A'  if  and 
only  if  for  all  l  :  T'  e  A',  there  is  some  T  <:  T'  such  that  l  :  T  e  A. 

Using  these  formal  helpers,  we  can  state  and  prove  a  preservation  theorem. 

THEOREM  3.5  (PRESERVATION).  If  e  is  a  closed  expression,  A  b  e  :  T  H  A", 
p.  A,  p  ok,  hdref(e),  p  be  me,  and  p,  p,e  — >  p! ,  p' ,  e'  then  for  some  A',  A'  b  e'  :  T  -\  A1", 
p\  A',  p'  ok,  p'  b  e!  me,  and  A'"  <l  A". 

PROOF.  By  induction  on  p,p,e  — >  p!,p',e!.  □ 

3.6.  Single-Heap  Implementation  Model 

As  we  have  previously  mentioned,  the  environment  in  the  FT  dynamic  semantics  is 
specifically  a  tool  for  proving  type  safety.  In  particular,  we  need  indirect  references 
so  that  we  can  independently  track  the  permissions  to  a  particular  object  held  by  in¬ 
dividual  aliases.  Similarly,  hold  and  merge  expressions  only  play  a  role  in  statically 
allocating  permissions,  and  need  not  be  considered  after  type  checking  FT  programs. 
Here  we  formally  show  that  a  practical  implementation  of  the  language  can  use  a  tra¬ 
ditional  heap  and  can  do  without  hold  and  merge.  Figure  9  presents  the  rules  (prefixed 
by  “SI”:  “S”  for  static,  “l”  for  implementation).  The  implementation  semantics  almost 
exactly  matches  the  dynamic  semantics,  but  leaves  out  the  extra  layer  of  indirection 
imposed  by  indirect  references  l  and  environments  p.  Note  as  well  that  there  are  no 
rules  for  hold  or  merge.  This  is  because  Featherweight  Typestate  does  not  need  to 
track  runtime  permissions  in  practice.  The  hold  expression  is  a  purely  static  means  of 
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P,e  -»  P,e' 


(Sinew) - 


o  ^  dom(p) 


(Slupdate)- 


(Slswap)- 


p,  new  C(o')  — >  p[o  >-»  C(o')\,  o 

p,  ( Ot  «-  C(o))  ->  p[ot  >->  C(o)],  void 

Moi)  =  fields  (C)  =YJ 

P,  Oi.fi  ■  =  ■  02  ->  m[oi  H-).  C(-  •  •  02  ■  ■  ■  )],  o' 


(Sllet)- 


(Slfield) 


p,  let  *  :  T  =  v  in  e  — >  p,  [r/x]e 
ju(o)  =  C(o')  fields (C)  =  T  f 


(Slassert)- 


li,o. fi  ->  p,  o' 
p(o)  =  C(-  •  • )  CcD 


p,  assert(P  D)(o)  — >  /i,  void 


(Slinvoke) 


a(o)  =  C(-  •  ■ ) 

method(m,  C )  =  Tr  m(T  »  T'  x)  [Tt  »  Tt']  {  return  e;  } 


(SIcongr) 


p,  o.m(o')  — *  p,  [o'/x][o/this]e 


Mi  el  -*•  A  ,  el 


p,  let  x  :  T  =  ei  in  e2  — *  p  ,  let  x  :  T  =  ej  in  e2 

Fig.  9:  FT  Implementation  Semantics 


controlling  permission  flows,  and  merge  is  merely  a  technical  device  for  proving  type 
safety,  so  the  implementation  semantics  for  FT  can  discard  them. 

We  define  a  simulation  relation  ~  between  Dynamic  Semantics  configurations  and 
Implementation  Semantics  configurations. 


P,P,e  -  p,p(£(e)) 

Where  the  erasure  function  £ (e)  is  the  natural  extension  of  the  following  equations: 

5(hold[Z  :  T](e))  =  5(e) 

5(merge[Zi  :  T/l2](e)  =  5(e) 

and  where  p(e)  is  the  natural  extension  of  p(l)  to  arbitrary  expressions.  Note  that  this 
relation  is  defined  up  to  choice  of  object  references. 

Proposition  3.6. 

( 1 )  If  e  is  a  source  program,  then  0,0,  e  ~  0, 5(e). 

(2)  If  p\,pi,e\  ~  Pi,e[  and  pi,  p,ei -*  p2,  p2,e2  then  p[,  e[  —>*  p'2,  e'2  and 
p2,  p2,e-2  ~  p2,  d2,  for  some  store  p'2,  and  some  expression  e2. 

Proof. 

(1)  Immediate. 

(2)  by  induction  on  qi,pi,  ei  ->  g2,p2,e2. 

□ 

3.7.  Discussion 

In  the  design  of  Featherweight  Typestate  we  made  a  number  of  decisions  based  on 
the  desire  to  simplify  the  resulting  calculus.  We  now  discuss  these  decisions  and  their 
alternatives. 

Method  calls.  In  FT,  two  particular  restrictions  on  method  calls  are  made  to  sim¬ 
plify  the  type  system  design  for  clarity  of  presentation.  First,  the  (STinvoke)  rule 
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enforces  that  a  variable  may  be  passed  only  once  as  an  argument  to  a  method  call. 
For  example,  xi.m(x2,X2)  would  never  type  check  because  X2  is  passed  as  the  argu¬ 
ment  for  two  method  parameters.  Type  checking  duplicated  arguments  like  these  adds 
substantial  complexity  to  the  type  system  and  the  type  safety  proof  specifically  be¬ 
cause  method  parameters  change  state.  For  instance,  suppose  that  m  were  declared  as 
Void  m(Tj  »  T2,  Ti  »  T3)[T  »  T],  where  T2  #  T3.  Then  the  question  arises:  what  is  the 
type  of  X2  after  the  method  call?  One  could  define  a  sensible  merging  of  T2  and  T3  as  its 
output  type.  However,  this  is  not  sufficient  because  when  proving  type  preservation, 
a  single  indirect  reference  would  be  substituted  for  two  different  method  parameters 
into  a  method  body  that  was  type  checked  using  two  independent  variables.  One  so¬ 
lution  in  the  formalism  is  to  use  a  generalized  form  of  merge  to  temporarily  split  a 
reference  into  two  references  for  the  dynamic  extent  of  the  method  call. 

The  second  simplification  we  make  to  method  calls  is  that  when  a  method  call 
takes  a  variable  argument,  it  drops  permissions  on  the  floor.  For  example,  consider 
the  method  call  xi.m(x2)  where  x2  has  type  full(Object)C  but  the  method  is  declared 
as  Void  m(pure(Object)C  »  pure(Object)C)[T  »  T].  Then  the  extra  full  permission  is  lost 
during  the  call  and  is  not  recovered  after  the  method  returns.  A  practical  version  of 
this  language  would  allow  methods  calls  to  preserve  extra  permissions  so  that,  for  in¬ 
stance,  X2  could  recover  its  full  permission.  We  can  use  hold  to  implement  this  explicitly 
in  our  model  language:  a  practical  language  would  integrate  hold  semantics  directly 
into  method  calls. 

Method  overriding.  For  clarity  and  simplicity,  the  language  definition  provides  con¬ 
servative  constraints  on  what  counts  as  a  legal  method  override.  The  overriding  rule 
from  Figure  6  says  that  the  overriding  method’s  signature  must  match  the  superclass 
method  exactly  except  that  the  incoming  class  of  the  receiver  object  must  be  the  class 
in  which  the  override  is  being  declared.  One  side-effect  of  this  restriction  is  that  call¬ 
ing  an  overridden  method  on  an  object  of  statically  known  subclass  type  can  lose  type 
information.  For  example,  consider  two  classes: 

1  class  C  {  Void  m( ) [full(Object)  C  »  full(Object)  C]  {  ...  }  } 

2  class  D  {  Void  m( ) [full(Object)  D  »  full(Object)  C]  {  ...  }  } 

Because  of  the  method  type  restriction,  the  following  code: 

1  x  =  new  D ( ) ; 

2  x.m( ) 

results  in  the  type  of  x  being  C  rather  than  D.  This  particular  drawback  can  be  rectified 
by  loosening  the  restriction  on  the  output  type  of  the  receiver,  but  the  language  benefits 
much  more  from  a  generally  broader  notion  of  legal  method  overrides.  In  particular,  a 
method  can  be  a  legal  override  of  an  existing  method  if: 

(1)  The  input  permission  of  the  receiver  is  a  superpermission  of  the  overridden 
method’s  receiver  input  permission; 

(2)  The  input  class  of  the  receiver  must  match  the  current  class  definition,  which  is 
therefore  a  subclass  of  the  overridden  method’s  receiver  input  class.  Note  that  co- 
variance  in  the  receiver  class  is  standard  in  object-oriented  type  systems,  and  is 
sound  because  we  dispatch  on  the  receiver. 

(3)  The  output  type  of  the  receiver  is  a  subtype  of  the  overridden  method’s  receiver 
output  type; 

(4)  The  input  types  of  the  arguments  are  supertypes  of  the  overridden  method’s  input 
types; 

(5)  The  output  types  of  the  arguments  are  subtypes  of  the  overridden  method’s  output 
types;  and 
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(6)  The  return  type  is  a  subtype  of  the  overridden  method’s  return  type. 

Demotion.  The  process  of  demoting  environment  references  at  update  operations  is 
quite  coarse  in  the  current  design.  Many  objects  that  need  not  be  demoted  in  particular 
cases  are  currently.  For  example,  if  an  object  is  updated,  then  any  existing  environment 
variable  whose  type  is  unrelated  is  surely  not  an  alias  to  the  object  at  hand.  As  such, 
it  need  not  be  demoted.  In  addition,  methods  could  also  be  annotated  to  indicate  that 
they  do  not  perform  state  change.  Such  safe  methods  need  not  cause  any  variables  to 
be  demoted  when  they  are  called.  For  simplicity  of  presentation,  we  demote  uniformly. 

Kinds  of  permissions.  The  literature  on  modular  typestate  checking  with  permis¬ 
sions  ( e.g .  [Bierhoff  and  Aldrich  2007;  Naden  et  al.  2012])  introduces  other  kinds  of 
access  permissions,  such  as  none,  which  provides  no  guarantees  about  the  behavior 
of  other  aliases,  unique,  which  guarantees  that  there  are  no  other  usable  aliases,  and 
immutable,  which  guarantees  that  no  one  can  change  the  underlying  object.  Note  that 
the  semantics  of  none  and  unique  make  their  state  guarantees  essentially  irrelevant,  so 
each  could  be  limited  to  none  (Object)  and  unique  (Object )  respectively,  or  alternatively 
none  and  unique  could  be  treated  as  permissions  P  rather  than  access  permissions  k. 

We  integrate  full,  pure,  and  shared  into  Featherweight  Typestate  because  they  con¬ 
stitute  a  self-contained  and  representative  set  of  access  permissions,  especially  in  a 
language  that  supports  state  change  for  aliased  objects.  The  full  permission  embodies 
the  concept  of  granting  a  single  alias  the  ability  to  change  state  (much  like  unique); 
the  pure  permission  embodies  the  inability  to  change  state  (much  like  immutable);  and 
the  shared  permission  characterizes  support  for  multiple  sources  of  state  change.  The 
other  permissions  described  above  can  all  be  integrated  into  Featherweight  Typestate 
without  any  additional  machinery. 

In  general,  as  a  program  executes,  permissions  to  variables  get  split  and  are  strictly 
weakened.  There  are  many  ways  to  refine  the  static  type  system  in  order  to  increase 
expressiveness,  such  as  parametric  polymorphism,  fractional  permissions  and  borrow¬ 
ing  [Boyland  2003;  Boyland  and  Retert  2005;  Naden  et  al.  2012].  We  believe  that  hold 
is  a  simple  but  expressive  means  of  recovering  permissions,  and  is  complementary  to 
these  more  sophisticated  but  complex  mechanisms. 

Syntactic  sugar.  In  addition  to  increasing  expressiveness,  a  practical  language  could 
also  implement  some  convenient  shorthands  that  would  make  programs  more  concise 
while  retaining  their  expressiveness  and  precision.  For  example,  many  method  argu¬ 
ments  are  likely  to  have  the  same  incoming  and  outgoing  type.  A  language  can  abbre¬ 
viate  this  idiom  by  allowing  a  single  type  parameter  specification  T  x  to  be  equivalent 
to  an  identical  type  transition  specification  T  »  T  x. 

A  practical  typestate-oriented  language  could  easily  simplify  the  presentation  of 
class  field  types.  Since  field  types  must  be  invariant  under  demotion,  any  field  with 
pure  or  shared  access  permission  has  the  same  class  assumption  and  state  guarantee, 
e.g.  shared(C)  C.  In  these  cases,  a  field  type  can  be  abbreviated  to  include  the  access 
permission  and  a  single  class,  e.g.  shared  C.  In  the  case  of  full,  the  state  guarantee 
must  be  specified  to  be  precise,  though  the  same  abbreviation  could  have  the  same 
meaning  as  a  common  case. 

Unicity  of  typing.  As  with  many  object-oriented  languages,  the  FT  expressions  are 
not  uniquely  typed.  In  particular,  because  of  subtyping,  most  values  could  be  assigned 
many  possible  types.  This  absence  of  type  unicity  can  be  traced  specifically  to  the  vari¬ 
able  reference  rule  (STvar),  which  can  assign  to  a  variable  reference  any  subtype  of 
that  variable’s  current  type.  In  most  cases,  however,  the  type  of  a  variable  reference  is 
restricted  by  the  surrounding  context. 
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To  see  these  phenomena  in  practice,  consider  the  following  program: 

let  x  :  full(Object)  C  =  y  in  x 

The  type  annotation  on  x’s  declaration  restricts  how  (STvar)  applies  to  y:  the  type 
of  this  reference  must  match  the  annotation.  On  the  other  hand,  no  such  annotation 
constrains  the  reference  to  x  in  the  body  of  the  let.  Treated  as  an  entire  program,  this 
whole  expression  could  be  assigned  any  subtype  of  x.  In  fact,  because  programs  are  in 
A-normal  form,  this  flexibility  of  typing  manifests  only  for  the  top-level  program  type. 

Even  with  programs  in  A-normal  form,  it  is  possible  to  extend  Featherweight  Type- 
state  to  have  even  more  flexible  typing.  Such  changes  do  not  increase  the  expressive 
power  of  the  language,  but  they  do  make  some  programs  more  convenient  to  write. 
First,  type  annotations  on  let-bindings  could  be  elided  from  the  language,  thereby  re¬ 
quiring  the  type  system  to  guess  a  type  for  each  variable.  This  kind  of  design  would 
increase  the  nondeterminism  of  typing.  Consider  its  effect  on  the  program  above: 

let  x  =  y  in  x 


As  before,  the  reference  to  x  can  be  typed  many  ways.  However,  the  type  of  x  is  no 
longer  fixed  when  it  is  declared,  so  the  reference  to  y  can  be  typed  many  ways,  and  y’s 
output  type  varies  accordingly. 

Second,  a  full  subsumption  rule  could  be  added  to  the  language: 


(STsub) 


Ao  |—  e  :  Xj  —\  Ai  Ti 
Aq  F  e  :  T2  H  Ai 


<:T2 


Its  effect  would  be  to  allow  any  expression,  not  just  variable  references,  to  be  typed 
many  ways. 

These  two  proposed  changes  to  the  type  system,  and  their  increase  in  nondetermin¬ 
ism  of  typing,  add  no  significant  expressive  power  to  the  type  system.  Once  a  method 
body  is  type  checked,  any  extra  permissions  left  over  are  either  discarded  (in  the  case 
of  local  variables)  or  adjusted  to  match  the  method  interface  specification  (in  the  case 
of  method  arguments).  This  means  that  adding  subsumption  has  no  effect  on  the  set  of 
typeable  FT  programs.  Since  permissions  are  simply  a  type-checking  device,  and  have 
no  effect  on  runtime  behavior  in  FT,  there  is  no  particular  need  for  subsumption. 

We  find  in  the  next  section  that  such  nondeterminism  in  typing  is  incompatible  with 
a  runtime  treatment  of  permissions,  which  is  needed  to  support  gradual  typing.  In  that 
context  we  depend  on  the  determinism  of  typing  that  comes  from  the  design  presented 
in  this  section. 


4.  GRADUAL  FEATHERWEIGHT  TYPESTATE 

Despite  its  sophistication,  Featherweight  Typestate  cannot  statically  typecheck  all 
typestate-oriented  programs  that  one  might  want  to  write.  In  this  section,  we  present 
Gradual  Featherweight  Typestate  (GFT),  a  gradually  typed  [Siek  and  Taha  2007]  ex¬ 
tension  of  Featherweight  Typestate.  GFT  seamlessly  enhances  FT’s  static  type  system 
with  support  for  dynamic  typestate  checking.  To  support  GFT,  we  extend  concepts  of 
gradual  typing  to  encapsulate  the  sophistication  of  permissions,  typestate  change,  and 
modular  flow-sensitive  typing. 

4.1.  Considerations 

The  design  of  Gradual  Featherweight  Typestate  is  driven  by  several  interacting  forces. 
Here,  we  outline  three  primary  observations  that  inform  how  we  extend  Featherweight 
Typestate. 
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4.1.1.  Dynamic  typing.  The  most  visible  feature  of  a  gradually  typed  programming  lan¬ 
guage  is  the  presence  of  dynamically  typed  values.  To  support  this,  GFT  adds  a  dy¬ 
namic  type: 

T  ::=  •  •  •  |  Dyn 

The  type  system  treats  the  Dyn  type  with  greater  leniency:  type  checks  on  Dyn  values 
are  deferred  to  runtime. 

A  Dyn  typed  value  is  quite  different  from  an  object  with  Object  type.  This  can  be  seen 
by  looking  at  programs  (in  the  sugared  syntax  of  Section  2)  that  are  legal  with  a  Dyn 
value  and  not  legal  with  an  Object  value: 

full (Object)  Object  y  = 

Dyn  ydyn  =  y;  //  y's  type  does  not  change 
shared(Object)  Object  ystc  =  y;  //  y's  type  changes 

full(Object)  Object  xsl  =  ystc;  //  Type  error 
full(Object)  Object  xs2  =  ydyn;  //  Okay 

ystc.f(y);  //  Type  error:  no  method  f 
ydyn . f (y) ;  //  Okay 

//  Void  f( [full(Object)  Object  »  pure(Object)  Object])  [T  »  T] 
m.f(ystc);  //  Type  error:  incompatible  permissions 
m.f(ydyn);  //  ydyn  now  has  type  pure(Object)  Object 

Each  of  the  scenarios  above  captures  a  difference  between  static  types  and  dynamic 
types.  Assigning  a  statically  typed  variable  y  to  a  dynamically  typed  variable  ydyn 
does  not  change  y’s  permissions.  As  seen  in  Section  2,  this  is  not  generally  true  for 
static  types.  Furthermore,  assigning  y  to  ystc  may  fail  if,  for  example  y  were  pure. 
Conversely,  a  dynamic  variable  can  be  assigned  to  any  other  variable,  regardless  of 
its  type:  safety  is  checked  at  runtime.  However,  assigning  a  static  variable  to  another 
static  variable  is  always  checked.  Next,  method  calls  on  dynamic  objects  are  always 
safe,  and  any  arguments  are  treated  as  dynamic.  This  is  not  the  case  for  static  method 
calls.  Finally,  static  method  calls  on  static  objects  are  checked  for  conformance.  On 
the  other  hand,  a  dynamic  object  can  always  be  passed  as  an  argument  to  a  method 
call.  Note,  however,  that  the  type  of  the  dynamic  object  after  the  method  call  matches 
the  method  declaration.  Newly  discovered  static  information  is  not  automatically  dis¬ 
carded,  but  as  we  show  below,  a  program  can  choose  to  discard  this  type  information. 

On  the  surface,  adding  Dyn,  a  single  syntactic  difference,  is  the  only  necessary  addi¬ 
tion  for  gradual  typing,  but  this  small  interface  change  implies  substantial  underlying 
formal  and  implementation  machinery,  which  we  outline  in  this  section.  The  fact  that 
it  is  almost  trivial  syntactically  is  one  of  the  great  strengths  of  gradual  typing. 

4. 1.2.  Type  assertions.  Runtime  type  tests  are  at  the  heart  of  gradual  typing,  though 
they  need  not  appear  in  the  surface  syntax  of  a  gradual  language.  However,  type  tests 
in  the  form  of  casts  are  a  standard  feature  of  object-oriented  programming.  As  dis¬ 
cussed  earlier,  Featherweight  Typestate’s  assert  operation  is  analogous  to  traditional 
object-oriented  language  support  for  type  casting,  but  FT  does  not  track  runtime  infor¬ 
mation  about  permissions.  For  this  reason,  FT  assertions  cannot  manipulate  variable 
permissions.  Since  GFT  requires  runtime  permission  information  to  support  gradual 
typing,  we  can  expose  them  at  the  source  language  by  extending  the  semantics  of  assert 
to  manipulate  the  full  type  of  an  object  reference,  not  just  its  class.  For  instance,  using 
assert  the  method  call  example  from  Section  4.1.1  can  be  extended  to  revert  the  ydyn 
variable  back  to  Dyn. 
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m.f(ydyn);  //  ydyn  now  has  type  pure(Object)  Object 
assert<Dyn>(ydyn) ;  //  ydyn  now  has  Dyn  type. 


4.1.3.  Dynamic  Permissions  Need  Deterministic  Typing.  In  Section  3.7,  we  observed  that 
Featherweight  Typestate’s  type  system  could  be  made  more  nondeterministic  by  re¬ 
moving  type  annotations  on  let-bound  variables  and  by  adding  full  subsumption.  This 
kind  of  nondeterminism  would  be  problematic  for  the  semantics  of  a  gradual  language 
that  depends  on  dynamic  permission  tracking.  To  understand  this  phenomenon,  con¬ 
sider  the  following  hypothetical  example  in  a  gradual  language  with  the  above  exten¬ 
sions.  Suppose  x  has  type  full(Z?)  D,  and  that  class  C  has  one  field  of  type  pure(D)  D, 
and  consider  the  following  expression: 

let  y  =  x  in 

let  z  =  new  C(y)  in  z 

What  are  the  types  of  x  and  y  at  the  end?  The  answer  depends  on  what  type  was  given 
to  the  x  reference  when  it  was  bound  to  y.  If  x  was  given  type  full(D)  D,  then  x  would 
have  type  pure(  I))  D  and  y  would  have  type  full(D)  I);  but  if  the  reference  to  x  was 
given  type  pure(D)  D,  then  the  reverse  would  be  true:  x  would  have  type  full (D)D  and 
y  would  have  type  pure(D)  D;  finally  if  the  reference  to  x  were  given  type  shared  (i?)  D, 
then  both  x  and  y  would  end  up  with  that  type. 

This  flexibility  allows  many  more  programs  to  be  typed  without  the  programmer 
having  to  annotate  every  variable  binding,  or  change  those  annotations  as  the  pro¬ 
gram  changes,  but  such  nondeterminism  is  incompatible  with  dynamic  permission  as¬ 
sertions.  Suppose  we  extend  the  example  with  a  dynamic  assertion: 

let  y  =  x  in 

let  z  =  new  C(y)  in 

let  w  =  assert<shared(I?)  D)( y)  in  z 

Then  the  behavior  of  this  example  depends  on  how  the  types  are  resolved.  If  y  has 
shared  or  full  access  permission,  then  the  assertion  is  a  safe  “upcast”  that  always  suc¬ 
ceeds;  if  y  ends  up  with  pure  permission,  then  the  assertion  is  a  “downcast”  that  must 
be  checked  dynamically  (and  in  this  case  fails  because  x’s  full  permission  is  not  com¬ 
patible  with  a  shared  alias). 

These  issues  do  not  arise  in  FT  because  it  cannot  check  permissions  dynamically.  As 
such  it  only  needs  to  find  some  valid  typing,  after  which  the  permission  information  is 
discarded  for  runtime.  Gradual  typing,  on  the  other  hand,  can  detect  how  permissions 
flow  in  a  program  at  runtime,  so  permissions  must  have  some  deterministic  specifi¬ 
cation  if  gradually  typed  programs  are  to  behave  deterministically.  In  the  following 
development,  we  leverage  the  fact  that  FT  typing  is  more  deterministic  than  strictly 
necessary  to  support  dynamic  permissions  and  thereby  support  gradual  typing  as  a 
pure  extension.7 

4.2.  Making  Featherweight  Typestate  Gradual 

Now  that  we  have  brought  to  light  the  primary  challenges  of  developing  a  gradually 
typed  typestate-oriented  language  like  Gradual  Featherweight  Typestate,  we  can  pro¬ 
vide  an  overview  of  the  language  and  describe  how  its  design  addresses  these  consid¬ 
erations. 


7As  shown  in  [Wolff  et  at.  2011],  a  typestate-oriented  language  can  simultaneously  enjoy  deterministic 
typing  and  low  annotation  overhead. 
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T  ^  T/T 


Type  Splitting 


T  ^  Dyn/T 


Consistent  Subtyping 


Ti  <:  T2  _ 

Ti  T2  Dyn  <  T 


Fig.  10:  Hybrid  Permission  Management  Relations 


A  b  e  :  T  H  A 


Source  Expression  Typing 


(GTvard) 


A,  X  :  Dyn  b  x  :  T  b  A,  x  :  Dyn 


(GTupdatea) 


fields(C)  =  T  f 
A  b  x2  ■■  T  H  A', ii  :  Dyn 
Abu*-  C(xi')  :  Void  H  A'|,xi  :  Dyn 


(GTfieldd) 


A,  a:  :  Dyn  b  a:./  :  Dyn  H  A  ,  tc  :  Dyn 


(GTswapd) - 

A,  tci 


A,  x i  :  Dyn  =  A',  x2  :  T 
:  Dyn  h  x\.f  :=:  x2  :  Dyn  H  A',x2  :  Dyn 


(GTinvoked ) - -  - 

A,  xi  :  Dyn,  x2  :  T2  \—  x±  .m('x2)  :  Dyn  H  Aj,xi  :  Dyn,  2:2  :  Dyn 


(GTassert) - 

A,  x 


:  T  \-  assert (T')(x)  :  Void  H  A,x  : 


T' 


Fig.  11:  Gradual  Featherweight  Typestate:  Expression  Typing  Extensions 


Aside  from  the  introduction  of  a  dynamic  type  Dyn,  the  syntax  of  GFT  is  the  same 
as  that  of  FT.  The  key  extensions  to  the  language  can  be  found  in  its  typing  rules  and 
its  runtime  semantics. 

4.2.1.  Managing  Permissions.  Now  that  the  Dyn  type  has  been  introduced  to  the  lan¬ 
guage,  we  must  consider  how  it  interacts  with  the  family  of  type  operations  that  sup¬ 
ports  typestate-oriented  programming 

Figure  10  presents  the  necessary  adjustments.  First,  type  splitting  is  extended  to 
account  for  Dyn.  In  particular,  any  reference  can  split  off  a  Dyn  without  affecting  its 
original  type  or  permissions.  This  captures  the  intuition  that  dynamically  typed  objects 
do  not  intrinsically  carry  any  permissions. 

Following  Siek  and  Taha  [2007],  we  replace  subtyping  in  our  rules  with  a  notion  of 
consistent  subtyping  T  T.  Consistent  subtyping  is  the  union  of  the  notion  of  type  con¬ 
sistency  T  ~  T  from  gradual  typing — which  codifies  possibly  safe  substitution — with 
the  notion  of  subtyping  T  <:T  for  Featherweight  Typestate — which  codifies  definitely 
safe  substitutability.  According  to  consistent  subtyping,  Dyn  T,  and  also  T  Dyn 
because  modified  type  splitting  now  forces  T  <:  Dyn  (See  Section  4.5).  We  restrict  the 
rules  to  ensure  determinism,  which  facilitates  our  translation  semantics. 

4.2.2.  Static  Semantics.  The  fundamental  differences  between  Featherweight  Types¬ 
tate  and  Gradual  Featherweight  Typestate  are  found  in  its  type  system.  All  of  FT’s 
typing  rules  are  valid  for  GFT,  so  Figure  11  presents  only  the  extensions  that  GFT 
adds  to  FT’s  type  system  (all  prefixed  with  “GT”:  G  for  “gradual  typing”  and  T  for 
“typing”). 

The  (GTassert)  rule  for  assert  subsumes  the  analogous  rule  in  Featherweight  Type- 
state,  though  now  it  considers  and  affects  the  entire  type  of  its  argument,  including 
in  particular  the  permissions  associated  with  an  object.  When  Ti  <:  7  j ,  the  assert  is 
statically  safe;  otherwise,  a  runtime  check  is  required  (see  Section  4.4). 
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l 

s 

b 

e 

es 


ed 

A 


ObjectRefs 

IndirectRefs 

X  I  l 
X  \  l  \  o 
es  |  ed 

b  I  void  I  s[T  ^  T/T ]  I  new  C(s) 

let  x  =  e  in  e  |  release[T](s)  |  s.f  \  s.m(s) 

s.f  :  =  :  s  |  s  <—  C(s)  \  assert (T  »  T)(s) 

hold[.s  :  T  ^  T/T  »  T  ee$>  T](e)  |  merge[( :  T/l 

s.df  |  s.dm(s)  |  s./  :=:d  s 

s  <—  d  C(s)  |  assertd(T  »  T)(s) 

b7T 


(simple  exprs) 

(bare  expr) 

(expressions) 

(statically  checked  exprs) 


:T^T](e) 

(dynamically  checked  exprs) 
(type  context) 


Fig.  12:  Internal  Language  Syntax 


The  full  language  adds  new  typing  rules  for  each  operation  in  the  case  when  the 
primary  object  being  operated  on  is  dynamically  typed.  The  rest  of  the  new  typing  rules 
account  for  how  Dyn-typed  references  to  objects  can  be  used,  as  well  as  their  effect  on 
permissions  and  type  information.  The  (GTvard)  rule  says  that  a  Dyn-typed  variable 
can  be  referenced  at  any  type.  Note  that  because  of  our  extensions  to  type  splitting, 
x  :  Dyn  can  already  be  typed  at  Dyn  using  FT’s  (STvar)  rule.  The  (GTupdate,/)  rule 
accounts  for  updating  a  dynamically  typed  variable.  The  type  system  checks  that  the 
arguments  to  the  constructor  are  suitable,  but  the  checks  on  the  target  of  the  update 
are  deferred  to  runtime  (see  Section  4.4).  The  (GTfield,/)  rule  says  that  accessing  a 
field  of  a  dynamic  object  yields  another  dynamic  object  (if  it  succeeds).  The  (GTswap,/) 
rule  allows  an  object  to  be  swapped  into  the  field  of  a  dynamic  object.  Permissions  are 
checked  at  runtime  for  safety.  Finally,  the  (GTinvoke,/)  rule  calls  a  method  with  objects 
of  any  type.  However,  the  output  type  of  the  method’s  arguments  are  all  dynamic,  since 
the  effect  on  their  permissions  cannot  be  known  until  runtime. 

4.3.  Internal  Language 

Gradually  typed  languages  are  characterized  in  terms  of  three  languages:  a  fully  stat¬ 
ically  typed  language,  the  gradually  typed  language  itself,  and  the  internal  imple¬ 
mentation  language.  For  instance,  the  original  work  on  gradual  typing  presented  the 
simply-typed  lambda  calculus,  the  gradual  lambda  calculus,  and  the  cast  calculus  as 
the  necessary  three  components  [Siek  and  Taha  2006],  Here  we  have  already  presented 
the  first  two  components:  Featherweight  Typestate  and  Gradual  Featherweight  Type- 
state.  We  must  now  introduce  our  analogue  to  the  cast  calculus. 

The  semantics  of  GFT  are  defined  by  type-directed  translation  to  GFTIL,  an  inter¬ 
nal  language  that  makes  the  details  of  dynamic  permission  management  explicit.  This 
section  presents  the  syntax,  type  system,  and  dynamic  semantics  of  the  internal  lan¬ 
guage.  Section  4.4  discusses  how  the  source  language  is  mapped  to  it. 

4.3.1.  Syntax.  GFTIL  is  structured  much  like  GFT  but  elaborates  several  concepts 
(Figure  12).  First,  the  internal  language  introduces  explicitly  dynamic  variants  e,/  of 
some  operations  from  the  source  language.  Static  variants  are  ensured  to  be  safe  by  the 
type  system;  dynamic  variants  require  runtime  checks.  Second,  many  expressions  in 
the  language  carry  explicit  type  information.  This  information  is  used  to  dynamically 
account  for  the  flow  of  permissions  as  the  program  runs.  These  type  annotations  play 
a  role  in  both  the  type  system  and  the  dynamic  semantics.  Finally,  GFTIL  adds  the 
same  runtime  constructs  as  were  added  to  Featherweight  Typestate:  object  references, 
indirect  references,  and  the  void  object. 
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In  GFTIL,  reference  expressions  come  in  two  forms.  A  bare  reference  b  signifies 
a  variable  or  reference  that  is  never  used  again.  In  contrast,  a  splitting  reference 
s[T  =-  T/T]  explicitly  specifies  the  starting  type,  result  type,  and  the  residual  type 
of  the  reference.  The  release[T](s)  expression  explicitly  releases  a  reference  and  its 
permissions,  after  which  it  can  no  longer  be  used. 

The  notion  of  a  well-typed  GFTIL  program  (see  Appendix  C)  is  almost  identical  in 
form  to  that  notion  in  FT.  One  notable  difference  is  the  typing  of  method  bodies:  since 
GFTIL  explicitly  tracks  resources,  it  requires  a  method’s  returned  value  as  well  as  the 
output  states  of  all  its  parameters  (and  this)  to  exactly  match  the  method  signature, 
for  which  release  [T](s)  is  introduced.  In  contrast,  both  FT  and  GFT  allow  subtyping  to 
implicitly  fill  the  gap. 

4.3.2.  Static  Semantics.  The  rules  for  GFTIL’s  typing  judgment  A  h  e  :  T  H  A  are 
defined  using  the  same  permission  and  type  management  relations  as  the  source  lan¬ 
guage.  GFTIL’s  typing  rules  explicitly  and  strictly  encode  permission  flow  by  check¬ 
ing  the  input  context  A  to  force  their  arguments  s  to  have  exactly  the  type  required. 
GFTIL’s  dynamic  semantics  uses  this  encoding  to  track  permissions. 

Figure  13  presents  some  of  GFTIL’s  typing  rules  (rules  are  prefixed  with  TI  for  “Typ¬ 
ing”  the  “Internal  language”).  For  brevity,  we  only  present  the  rules  for  invoke,  up¬ 
date  and  assert,  together  with  their  dynamically-typed  variants  here:  the  full  set  can 
be  found  in  Appendix  C.  The  (TIinvoke)  rule  matches  a  method’s  arguments  exactly 
against  the  method  signature.  Each  argument’s  output  type  is  dictated  by  the  method’s 
output  states.  The  (TIupdate)  rule  almost  mirrors  GFT’s  update  rule  except  that  its  ar¬ 
gument  types  must  exactly  match  the  class  field  specifications.  The  (TIassert)  rule  is 
the  safe  subset  of  GFT’s  rule,  though  GFTIL’s  assert  is  explicitly  annotated  with  its 
argument’s  source  type.  The  dynamic  variants  of  these  expressions  enforce  very  little 
statically:  the  (TIupdate^)  rule  only  checks  that  the  arguments  match  the  construc¬ 
tor,  and  the  (TIassert^)  rule  applies  when  the  destination  type  cannot  be  split  from 
the  source  type.  The  (TIhold)  rule  is  the  explicit  analogue  to  the  GFT  typing  rule.  The 
(TImerge)  rule  expresses  how  merge  annotates  the  expression  e  with  the  information 
needed  to  restore  the  held  permissions  Tj  back  to  reference  l2  after  e  completes.  The 
type  V2  of  / 2  after  e  completes  is  merged  with  Tj  to  give  l2  type  T3.  The  type  of  e  is  the 
type  of  the  whole  expression. 

4.3.3.  Dynamic  Semantics.  The  dynamic  semantics  of  GFTIL,  presented  in  Figure  14, 
depend  on  the  same  runtime  structures  as  Featherweight  Typestate:  environments 
p  and  stores  //..  One  significant  difference,  though,  is  that  GFTIL  heaps  map  object 
references  to  tracked  objects: 

C(o)  P  e  TrackedObjects 

fi  e  ObjectRefs  —  TrackedObjects  (stores) 

Expressions  in  the  language  evaluate  to  values,  including  void  and  object  references  o. 
Stores  /i  associate  object  references  to  objects.  The  novelty  of  GFTIL  is  that  an  object 
in  the  store  C(o)  is  annotated  with  the  collection  of  outstanding  permissions  for  ref¬ 
erences  to  that  object,  P.  The  dynamic  semantics  of  GFTIL  is  defined  as  transitions 
between  store/environment/expression  triples. 

Figure  14  presents  some  select  dynamic  semantics  rules  of  GFTIL  (prefixed  with 
GE,  for  “Gradual  typing”  and  “Evaluation”).  Certain  rules  use  two  helper  functions 
for  tracking  permissions  in  the  heap,  whose  definitions  are  given  in  Figure  15.  Per¬ 
mission  addition  +  augments  the  permission  set  for  a  particular  object  in  the  heap. 
Conversely,  permission  subtraction  —  removes  a  permission  from  the  set  of  tracked 
permissions  for  an  object.  Both  operations  take  an  arbitrary  value  and  type,  but  be- 
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mdecl(m,C i)  =  Tr  m(T2  »  T')[Pi  C i  »  Ti] 
(TIinvoke) - 

A,  Si  :  P\  C  i ,  S2  :  T2  \~  si-m(s2 )  :  Tr  — |  AJ,  Si  :  T[,  s  2  :  T ^ 


(TIinvoke  d ) - ^ - ^=^=- 

A,  si  :  Dyn,  s2  :  Dyn  h  si.jrafsi)  :  Dyn  H  AJ.,  si  :  Dyn,  s2  :  Dyn 

k  e  { full,  shared  }  C2  c  D  fields (C 2)  =  7V 

(TIupdate) - ^ - 

A,  Si  :  k{D)  C\ ,  s2  :  T  h  Si  <-  C2(s^)  :  Void  H  AJ,si  :  k(D)  C2 


(TI  update,/ )- 


fields(C2)  =T  S 


(TIassert) 


(Tlasserta)- 


A,  si  :  Dyn,  s2  :  T  hsi  <— a  C2(s2)  :  Void  H  AJ,  si  :  Dyn 
Ti  ^  T2 


A,  s  :  Ti  |—  assert<JTi  »  T2)(s)  :  Void  H  A,  s  :  T2 

_ Ti  #  T2 _ 

A,  s  :  Ti  I —  assertd(Ti  »  X^^fs)  :  Void  — I  A,  s  :  X2 


(TIhold) 


Ti  T2/T3  T2J  /Tj  T'i  A,  s  :  T3  |-  e  :  T  -J  Ai ,  s  :  X2 
A,  s  :  Ti  h  hold[s  :  Ti  T2/T3  »  Tj  T{](e)  :  T  H  Ai,s  :  T{ 


(TImerge) 


T’i  =  TjJ  Ti/T'^Ta  A,  (2  :  T2  h  e  :  T  -j  At ,  l2  :  T' 

A,  (1  :  Ti ,  l2  :  T2  l—  merge[ti  :  T\/l2  :  T2  ^  T3](e)  :  T  -\  Ai ,  l2  :  T3 


Fig.  13:  Select  Internal  Language  Typing  Rules 


have  like  identity  when  presented  with  a  type  that  does  not  represent  a  permission, 
like  Void  or  Dyn.  The  (GEinvoke)  rule  is  straightforward.  The  (GEupdate)  rule  looks 
up  the  object  references  for  the  target  reference  and  the  arguments  to  the  class  con¬ 
structor,  replaces  the  store  object  for  the  target  reference  with  the  newly  constructed 
object,  and  releases  the  permissions  held  by  the  fields  of  the  old  object.  The  (GEassert) 
rule  uses  permission  addition  and  subtraction  to  track  permissions,  and  returns  void. 
Rules  for  dynamic  operators,  like  (GEinvoke^)  and  (GEupdate^),  dynamically  assert 
the  necessary  permissions  (using  assertd),  defer  to  the  corresponding  static  operation, 
and  then  statically  release  the  acquired  permission  (using  assert).  The  (GEassert^) 
rule  confirms  dynamically  that  its  type  assertion  is  safe.  The  (GEhold)  rule  performs 
the  splitting  of  permissions  (one  permission  to  be  used  through  the  execution  of  the 
subexpression,  and  one  to  be  held  around  it),  and  evaluates  to  a  merge.  A  new  indirect 
reference,  l'  is  added  to  the  environment  as  an  alias  for  l  to  hold  the  permission  T2 1 
during  execution  of  e.  Finally,  the  (GEmerge)  rule  applies  when  the  subexpression  is 
fully  evaluated,  and  roughly  reverses  the  (GEhold)  rule.  It  merges  the  held  type  of  V 
with  the  type  of  its  alias  l,  and  updates  the  store  accordingly.  Note  that  after  this  point, 
the  indirect  reference  l'  is  no  longer  in  scope. 

4.3.4.  Type  safety.  As  for  FT,  the  type  safety  proof  of  GFTIL  must  account  for  the  out¬ 
standing  permissions  for  each  object  o  and  verify  that  they  are  mutually  compatible. 
Figure  16  presents  representative  updates  to  FT’s  permission  accounting  operations 
needed  for  GFTIL.  The  basic  reference  type  operations  must  be  updated  to  filter  out 
the  Dyn  type  and  to  expect  tracked  objects  rather  than  just  objects.  The  most  impor¬ 
tant  difference,  though,  is  that  when  checking  reference  consistency,  that  an  object  is 
ok  with  respect  to  a  context-environment-heap  triple,  it’s  now  necessary  to  check  that 
the  heap  is  properly  tracking  permissions. 

The  definition  of  global  consistency  does  not  change  from  that  of  FT.  Recall  that  un¬ 
der  global  consistency,  every  reference  in  the  type  context  is  accounted  for  in  the  store 
and  environment,  and  that  Void  and  object-typed  indirect  references  ultimately  point 
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M,P,  e  -*■  P,P,  e 


Dynamic  Semantics 


(GEinvoke) 


p(p(Zi))  =  C(o)  P 

method(m,  C )  =  Tr  m(Ti  »  T'  x)  \Tt  »  Tt']  {  return  e;  } 
p,  p,  li.mfo)  — >  p,  p,  [Zi,  Z2  /this,  x]e 


(GEinvoke,;) 


p(p(Z  1))  =  C(o)  P  mdecl(m,C)  =  Tr  m(Ti  »  T')  [Tt  »  T/]  |  Ti  |=|  Z2  | 

p,p,h-dm(l2)  — ►  p,  p,  assertd<Dyn  »  Tt>(Z  1);  assertd<Dyn  »  Ti>(Z 2); 

let  ret  =  Zi.m(Z2)  in  assert(Tt'  »  Dyn)(Zi); 
assert(T/  »  Dyn)(Z2);  assert(Tr  »  Dyn)(ret); 
ret 


p(p(M) 

(GEupdate) - 


C(o)P  fields (C)  =  T  f  p’ =  (p[p{h)  ^  C\p{l2))  P])  -  o  :  T 
p,  p,  h  <-  C'{h)  ->  p',  p,  void 


(GEupdate^) 


p(p(Zi))  =  C(oJ)  P 
P,  p,  Zi  <—  d  C'(l 2) 


D9  =  A  {D  |  fc(D)  e  P}  C'  <:  Dg 

p,p,  assertd<Dyn  »  shared(T>9)  <7>(Z  1); 
Zi  -  C"(Z2); 

assert<shared(Dg)  C"  »  Dyn)(Zi) 


(GEassert) 


p'  =  P  -  p(Z)  :  T  +  p(Z)  :  T' 
p,  p,  assert(T  »  T')(Z)  — >  p',p,  void 


(GEassertdv) 


p(Z)  =  void 

p,  p,  assertd(Dyn  »  Void)(Z)  — »  p,  p,  void 


p(Z)  =  0  p'  =  p  —  o  :  T  +  o  :  P1  C1  p'(o)  =  C(ot )  P  C  <:  C'  P  compatible 

(GEassertdo) - - — - - - - 7 - 

p,  p,  assertd(T  »  P  C  )(Z)  — *  p  ,  p,  void 


(GEhold) 


p'  =  p  -  p(Z)  :  Tj  +  p(Z)  :  Ta  +  p(Z)  :  P3  Z'  $  dom(p)  p'  =  p[Z'  >->  p(Z)] 

P,  p,  hold[Z :  Ti  =*•  T2/T3  »  ^  Ti](e)  —  p',  p',  merge[Z'  :  T2|  /Z :  I?  ^  T[](c) 


(GEmerge) 


p'  =  p  -  p(Z')  :  Ti  -  p(Z)  :  T2  +  p(Z)  :  T3 
p,  p,  merge[Z'  :  Ti/Z :  T2  P3](r)  -*•  p',  p,  v 


(GEmcongr)- 


p,p,e  -►  p  ,p  ,e 


P,P,  merge[Zi  :  T/Z2](e)  -►  p',p',  merge[Zi  :  T/Z2](e') 

Fig.  14:  Select  Internal  Language  Dynamic  Semantics  Rules 


fx  =  \x  +  v  :  T 


Permission  Addition 


T  e  {Dyn,  Void} 

fx  =  (x  +  v  :  T 

_ p(o)  =  C(oj)  P _ 

p[o  C(oj)  P,P']  =  p  +  o:  P'  C" 


fj,  =  H  —  v  :  T 


Permission  Subtraction 


/x  =  fx'  +  :  T 

fx'  =  fx  —  v  :  T 


Fig.  15:  Internal  Dynamics  Auxiliary  Functions 
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Helper  Functions 

fieldTypes(g,  o)  =  -) — |-  IVi  ^  Dyn  |  p(o')  =  C(o")  P2  ,  fields(C)  =T  /,  o"  =  o,  and  71  #  Dynl 

o'€dom(i u) 


p,  A,  p| —  o  ok 


Reference  Consistency 


p{6)  =  C(o')  fc(F)  | o' |  =  |/ieZds(C) 

refTypes(p,  A,  p,  o)  =  k(E)  D 
C  <:  D  k(E)  compatible 

g,  A,  p  \-  o  ok 


Fig.  16:  Changes  to  Permission-Consistency  Relations 


to  void  values  and  object  references  respectively.  In  extending  to  GFT,  Dyn-typed  refer¬ 
ences  can  be  ignored  because  they  may  point  to  anything.  Note  that  global  consistency 
and  permission  tracking  take  into  account  even  objects  that  are  no  longer  reachable  in 
the  program.  To  recover  permissions,  a  program  must  explicitly  release  the  fields  of  an 
object  before  it  becomes  unreachable. 

These  concepts  contribute  to  the  statement  (and  proof)  of  type  safety. 

THEOREM  4.1  (Progress).  If  e  is  a  closed  expression,  /x,  A,  p  ok,  and 
A  h  e  :  T  H  A1,  then  only  one  of  the  following  holds: 

—  eis  a  value; 

—  p,  p,  e  — >  //,  p' ,  e '  for  some  //,  p' ,  e! ; 

—  e  =  E  [erf]  and  g,  p ,  e  is  stuck. 

The  last  case  of  the  progress  theorem  holds  when  a  program  is  stuck  on  a  failed  dy¬ 
namically  checked  expression.  All  statically  checked  expressions  make  progress. 

Theorem  4.2  (Preservation).  If  A  b  e  :  T  -\  A',  and  p,  A,  p  ok,  and 
p  he  me,  and  p,  p,  e  — >  p1,  p',  e! ,  then  A"  I —  e'  :T  -\  A'  and  p' ,  A",  p'  ok,  and  p'  \-  e!  me 
for  some  A". 

4.4.  Source  to  Target  Translation 

The  dynamic  semantics  of  GFT  are  defined  by  augmenting  its  type  system  to  generate 
GFTIL  expressions.  The  typing  judgment  becomes  A  h  e\  :  T  ef  H  A',  where  e\  is 
a  GFT  expression  and  ef  is  its  corresponding  GFTIL  expression.  Figure  17  presents 
these  rules.  We  use  the  X  superscript  to  disambiguate  GFTIL  expressions  as  needed. 
Several  rules  use  the  coerce  partial  function,  which  translates  consistent  subtyping 
judgments  T  T  into  variable  assertions: 

coerce (x,  Tj,  T2)  =  assert(Ti  »  T2){x)  if  T)  <:  T2 

coerce (x,  Dyn,T)  =  assertd(Dyn  »  T)(x)  if  T  ^  Dyn 

Most  of  the  translations  are  straightforward,  and  follow  similar  patterns.  For  in¬ 
stance,  the  (TRupdate)  rule,  which  applies  when  the  target  of  the  update  is  statically 
typed,  let-binds  all  of  the  arguments  to  the  object  constructor  so  as  to  extract  the  exact 
permissions  that  it  needs  before  calling  GFTIL’s  static  update.  The  (TRupdate^)  rule, 
in  contrast,  applies  when  the  target  of  the  update  is  dynamically  typed.  It  translates 
to  a  dynamic  update  operation  <—  d,  but  is  otherwise  the  same.  Operations  on  dynami¬ 
cally  typed  objects  translate  to  dynamic  operations.  Other  rules  like  (TRassert)  simply 
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A  h  e  :  T  e1  H  A 


Source  to  Internal  Language  Translation 


(TRvar) 


_ Ti  ^  T2/T3 _ 

A,  x  :  Ti  I-  x  :  T2 
x[Ti  T2/T3]  H  A,  x  :  T3 


(TRvard) 


A,  X  :  Dyn  hi:T 


T  #  Dyn 

let  ret  =  a;[Dyn  ^  Dyn/Dyn]  in 
assert3(Dyn  »  T)(ret); 
ret  — \  A,  x  :  Dyn 


(TRlet) 


Ahei:Ti^ef  HAi 
Ai,  x  :  Ti  |—  e2  :  T2  — |  A^,  x  :  T[ 

A  b  let  x  :  Ti  =  ei  in  e2  :  T2  -"•* 
let  x  =  in 
let  ret  =  e \  in 
release [T{](x); ret  H  A' 


(TRnew) 


fields  (C)  =  T  f  A\-  x  :  T  ^  e1  -\  A' 
A  b  new  C(x)  :  full  (Object)  C 

let  x'  =  ex  in  new  C(x' )  H  A' 


(TRinvk) 


mdecl(m,  Ci)  =  T  m(T*  »  T')[Tt  »  T'] 
coerce(x\,  P\  C±,Tt)  =  ef 
coerce (x 2,  T2,Ti)  =  ex 
A,xi  :  Pi  Ci ,  X2  ■  T2  b  x\.m{x2)  :  T 
ef;  ex;  x\  .m(x^)  —\  Af,  xi  :  T't ,  X2  :  Tf 


(TRswap) 


T2  f  E  fields^) 

A,  xi  :  Pi  Ci  b  x2  :  T2  ef  H  A' 
A,  xi  :  Pi  Ci  b  xi./  :=:  x2  :  T2 
let  X2  =  ej  in  xi./  :=:  X2  — I  A; 


(TRinvk^) 


coerce (x 2,  T2,  Dyn)  =  e^ 

A,  xi  :  Dyn,  X2  :  T2  b  xi.ra(xj)  :  Dyn 
e^ ;  xi  ■d'm(^)  H  Af,  xi  :  Dyn,  X2  :  Dyn 


(TRswap  <2 ) 


A,  xi  :  Dyn  =  A;,  X2  :  T 

A,xi  :  Dyn  b  X±.f  X2  :  Dyn 
assert<T  »  Dyn)(x2); 
let  X2  =  x2[Dyn  ^  Dyn/Dyn]  in 

X\.f  :  =  :<2  H  A',x2  :  Dyn 


(TRupdate) 


fields  (C)  =  T  f 

A  b  #2  :  T  ^  ex  ~\  A/ ,  xi  :  k(D)  E 
k  e  {full,  shared}  C  c  D 

A  b  £1  <—  C(x^)  :  Void  ^ 
let  x'2  =  ex  in 

x  1  <-  C(a£)  H  A'|,xi  :  fc(£>)  C 


(TRupdate  d ) 


fields  (C)  =  T2  f 
A  b  X2  :  P2  ^  ef  H  A',xi  :  Dyn 
A  b  x\  <—  C(x^)  :  Void 
let  x^  =  ex  in 

x\  <—  d  C(xf2)  H  A'i,  xi  :  Dyn 


(TRfield) 


T2fE  fields {C 1)  T2]}T' 

A,x  :  Pi  Ci  b  a:./  :  T2 
x .  /  H  A ,  x  :  Pi  Ci 


(TRfieldd) 


A,  x  :  Dyn  b  x.f  :  Dyn 
x.df  H  A,  x  :  Dyn 


T  ^  T' 

(TRassert) - — 

A,  x  :  T  b  assert(T  ) 
assert(T  »  T'}(x)  - 


-  (TRassert^) 

x)  :  Void 

|A,x:T' 


T  T' 

A,  x  :  T  b  assert(T/)(x)  :  Void 
assertd(T  »  T')(x)  H  A,  x  :  T' 


(TRhold) 


Ti  T2/T3  T2|  /T3  ^ 

A,  x  :  Ts  b  e  :  e1  H  A;,x  :  T3 

A,  x  :  Ti  b  hold[x  :  T2](e)  :  T  ^ 
hold[x  :  Ti  T2/T3  »  T3  Tj](e2:) 
H  A',a  :  T( 


Fig.  17:  Type-directed  Translation  from  GFT  to  GFTIL 


use  the  typing  rule  to  expose  the  needed  extra  type  annotations  for  the  corresponding 
GFTIL  expression.  The  (TRhold)  rule  specifies  how  the  source-level  hold  is  translated 
to  the  internal  expression,  which  is  fully  annotated  with  the  intermediate  types  used 
in  the  derivation. 

As  intended,  the  translation  rules  preserve  well-typing: 

Theorem  4.3  (Translation  Soundness). 

If  A  b  e  :  T  e1  -\  A'  then  A  | -  e1  :  T  -\  A'. 
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This  theorem  extends  straightforwardly  to  whole  programs. 


4.5.  Discussion 

In  Featherweight  Typestate,  permissions  are  a  compile-time  phenomenon  and  need 
not  be  represented  at  runtime.  However,  permissions  are  an  integral  component  of  FT 
types,  so  being  able  to  reason  about  them  at  runtime  is  critical  to  support  the  dynamic 
type  checking  that  is  at  the  heart  of  gradual  typing.  For  this  reason,  Gradual  Feather¬ 
weight  Typestate  is  designed  to  support  runtime  tracking  and  querying  of  permissions. 

In  order  to  achieve  this  combination  of  static  and  dynamic  typestate  checking,  sev¬ 
eral  challenges  needed  to  be  overcome.  First,  given  that  the  language  includes  objects 
whose  type  changes  over  time,  it  is  necessary  to  determine  what  might  be  a  reason¬ 
able  behavior  for  dynamically  typed  objects.  Since  dynamically  typed  objects  include 
object  references  that  would  otherwise  have  permissions  associated  with  them,  it  was 
necessary  to  introduce  a  notion  of  runtime-checked  permissions,  a  feature  that  could 
also  be  applied  to  purely  dynamically  typed  typestate-oriented  languages.  Nonethe¬ 
less,  this  change  alone  necessitated  removing  non-determinism  from  the  type  system 
of  FT,  while  still  providing  a  convenient  programming  model. 

Once  runtime  permission  tracking  and  dynamic  assertions  are  added,  the  introduc¬ 
tion  of  the  Dyn  type  of  gradual  typing  can  be  viewed  as  a  pure  language  extension, 
since  any  program  with  no  Dyn  types  falls  in  the  non-gradual  subset  of  the  language. 
To  keep  the  development  simple,  our  presentation  introduces  gradual  typing  by  mak¬ 
ing  some  modifications  to  the  existing  permission  management  operations  and  typing 
rules.  However,  the  Dyn  type  could  have  been  introduced  to  GFT  as  a  pure  extension 
atop  the  language  with  dynamic  type  assertions.  First,  we  could  have  preserved  a  full 
separation  between  dynamic  typing  and  type-splitting/sub  typing  by  only  specifying 
that  Dyn  =>  Dyn/Dyn,  which  is  standard  for  any  type  that  does  not  track  permissions 
(like  Void).  We  could  then  have  introduced  a  distinct  notion  of  dynamic  type  splitting 
T  ~  T/T  solely  for  handling  the  special  properties  of  the  Dyn  type.  Its  two  rules  would 
be  T  ~  Dyn /T  and  Dyn  ~  T/ Dyn.  The  type  system  could  then  be  extended  with  special 
rules  for  checking  variables  and  complex  expressions  at  Dyn,  as  well  as  checking  Dyn- 
typed  variables  at  non-dyn  types.  Furthermore,  we  could  define  consistent  type  split¬ 
ting  as  the  union  of  standard  type  splitting  and  dynamic  type  splitting.  This  would 
lead  to  the  definition  of  consistent  subtyping  that  we  ultimately  used,  though  by  a 
more  circuitous  route.  We  found  it  simpler  to  allow  Dyn  to  be  the  head  of  the  subclass 
hierarchy  and  then  extend  subtyping  to  consistent  subtyping  directly. 

In  Featherweight  Typestate,  hold  is  a  purely  static  notion,  and  supports  the 
permission-based  type  discipline,  but  is  not  needed  at  runtime.  In  a  gradually-typed 
setting,  however,  we  must  account  for  temporarily-held  permissions  at  runtime,  so 
both  hold  and  merge  have  GFTIL  counterparts  that  implement  the  necessary  permis¬ 
sion  bookkeeping.  Compared  to  prior  work  on  borrowing,  the  semantics  of  hold  is  novel 
in  two  ways  that  can  be  ascribed  to  its  straightforward  and  effective  integration  with 
gradual  typing.  First,  in  order  to  provide  a  static  guarantee  that  the  held  permissions 
remain  valid,  hold  must  do  runtime  bookkeeping  to  ensure  that  the  code  inside  the 
nested  block  does  not  assert  an  incompatible  permission.  Second,  hold  does  not  al¬ 
ways  restore  the  exact  original  permission;  rather,  it  agnostically  the  held  permission 
with  the  available  pending  permissions.  Because  of  dynamic  assertions  that  can  occur 
within  the  nested  block,  the  merged  permission  may  be  stronger  or  weaker  than  the 
original  permissions.  Borrowing  has  to  date  been  conceived  only  in  a  static  context, 
and  it  recovers  exactly  the  permissions  that  were  loaned  to  a  function  call.  It  remains 
to  be  explored  how  borrowing  interacts  with  dynamic  permission  assertion. 
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5.  GFT  SIMPLY  EXTENDS  FT 

The  prior  sections  present  two  source  languages,  Featherweight  Typestate  and  Grad¬ 
ual  Featherweight  Typestate,  as  well  as  type  systems  and  operational  semantics  for 
both.  However,  despite  the  presence  of  two  separate  operational  semantics,  we  claim 
that  GFT  is  simply  an  extension  of  the  FT  language,  with  support  for  gradual  typing 
and  dynamic  permission  management.  This  section  clarifies  the  sense  in  which  this  is 
so. 

We  start  with  the  syntax  and  static  semantics  of  these  languages.  As  discussed  in 
Section  4,  FT  is  syntactically  a  subset  of  GFT,  with  the  only  extension  being  the  addi¬ 
tion  of  the  Dyn  type.  Furthermore,  GFT’s  type  system  accepts  all  FT  programs.  So  the 
syntax  and  static  semantics  of  the  two  languages  are  in  sync. 

From  here,  however,  things  appear  to  diverge.  We  give  FT  a  direct  operational  se¬ 
mantics.  On  the  other  hand,  GFT  is  defined  by  type-directed  translation  to  GFTIL, 
an  intermediate  language  that  is  given  its  own  operational  semantics,  independent  of 
that  of  FT. 

To  complete  the  connection  between  FT  and  GFT,  we  bridge  the  difference  between 
these  operational  semantics.  In  particular,  since  every  FT  program  is  also  a  GFT  pro¬ 
gram,  we  show  that  translating  an  FT  program  to  GFTIL  and  then  running  it  produces 
the  same  behavior  as  running  the  FT  program  directly. 

The  key  observation  underlying  this  connection  is  that  many  GFTIL  expressions 
are  designed  to  maintain  proper  permission  accounting  so  that  information  may  be 
queried  whenever  runtime  permission  checks  are  needed.  FT,  being  a  static  language, 
never  needs  to  query  runtime  permissions  (though  assert  may  check  class  identity  in 
the  case  of  a  downcast).  Furthermore,  as  shown  in  Section  3.6,  indirect  references  and 
their  environment  are  irrelevant  to  the  behavior  of  programs:  it’s  the  structure  of  the 
heap  that  matters.  Thus,  we  want  to  show  that  FT  programs  produce  the  same  heap 
structures  when  run  on  the  FT  semantics  and  the  GFTIL  semantics. 

The  relationship  between  FT,  GFT,  and  GFTIL  programs  is  reminiscent  of  the  con¬ 
nection  between  Siek  and  Taha  [2006]’s  simply  typed,  gradually  typed,  and  cast  calcu¬ 
lus  programs.  Every  simply-typed  program  is  also  a  gradually-typed  program  and  thus 
translates  to  a  cast  calculus  program  which  has  the  same  semantics.  The  correspon¬ 
dence  between  semantics  in  their  system  is  immediately  evident  and  needs  no  proof. 
In  our  present  case,  we  must  account  for  GFTIL’s  strict  permission  tracking  and  show 
that  it  does  not  affect  the  behavior  of  FT  programs. 

First,  we  establish  what  it  means  for  an  FT  state  and  a  GFTIL  state  to  be  in  corre¬ 
spondence.  We  must  appeal  to  the  GFT  translation  for  this. 

Definition  5.1.  Let  Ah/(,  p,  e  ~  //x,  pz,  e1  if  and  only  if 


(1) 

p,  A,pok; 

(2) 

P-1,  A,  px  ok; 

(3) 

m  =  \px\i 

(4) 

p  c  p1; 

(5) 

A  b  e  :  T  ex 

H  Ai; 

(6) 

ex  expands  to 

ex;  and 

(7) 

A  h  e1  H  A2; 

The  above  definition  relies  on  several  auxiliary  concepts.  The  |pz|  operation 
converts  a  GFTIL  heap  pz  to  an  FT  heap  by  discarding  permission  informa¬ 
tion.  Also,  the  relation  ez  expands  to  ez  is  defined  by  the  following  rules: 
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(release) - 


ef  expands  to  ef 


ef  expands  to  let  ret  =  ef  in  release[T](Z);  ret 


(assert) - 


ef  expands  to  ef  C  <:  D 


ef  expands  to  let  ret  =  ef  in  assertfP  C  »  P  ret. 


(refl)  - 


e  expands  to  e2 3 


(let) 


expands  to  ef  ef  expands  to  ef 
let  x  =  ef  in  ef  expands  to  let  x  =  ef  in  ef 


This  relation  accounts  for  the  extra  code  added  by  the  translation  of  let  expressions 
and  method  bodies. 

The  resulting  correspondence  A|-  p,p,e~  p1,  p1 ,  ex  captures  the  idea  that  we  can 
consider  an  FT  and  GFTIL  state  to  be  in  sync  if  they  are  the  same  apart  from  indirect 
references  and  permission  tracking  steps. 

Armed  with  these  definitions,  we  can  establish  correspondence. 

Proposition  5.2. 

(1)  If*  h  e  :  T  ^  e1  h  •  then  •  h  0,  0,  e  -  0,  0,  e1. 

(2)  Let  ef  be  one  of: 

(a)  a  value  v; 

(b)  a  reference  l \'I\  A  T2/X3];  or 

(c)  an  assertion  assert (T  »  T)(l). 

If  ef  expands  to  ef,  p.  A,  p  ok,  A  I  ef  :  T  I  A',  and  p1,  pf ,  ef  - 

"  ~  ~  ~ 


:xxx 


P",  Pi,  e2  — p£ ,  pj ,  v  where  p2  c  p3. 

(3)  If  Ai  h  Pi,Pi,e  1  -  pf,pf,ef  and  pi,pi,ei 


p,  pf ,  w  Z/ien 


and  A2  h  P2>  P2j  e2 

Proof  Sketch. 


fif, 


pf, 


/or  some  A2 


p2,P2,e2  then  pf,pf,ef 


fif, 


pf, 


(1)  Straightforward 

(2)  By  induction  on  ef  expands  to  ef . 

(3)  By  simultaneous  induction  on  p\,pi,e\  — »  p2,  p2,  e2  and  ef  expands  to  ef . 

Cases  (SEassert)  and  (SEinvoke)  make  explicit  use  of  well-typed  translation.  In 
particular,  Some  assert  expressions  in  FT  translate  to  assert^  in  GFTIL,  but  they 
never  modify  the  permissions,  only  the  class. 

To  account  for  the  let-bound  arguments  introduced  by  translation,  cases  (SEnew), 
(SEupdate),  and  (SEinvoke)  appeal  to  part  (2)  and  use  a  nested  simultaneous  in¬ 
duction  on  the  ef  expands  to  ef  relation  and  the  number  of  let  bindings  in  ef . 
Finally,  to  properly  translate  running  programs,  we  extend  (TRref)  to  include  indi¬ 
rect  references  and  add  the  following  rules: 


(TRvoid)- 


A  h  void  :  Void  void  h  A 


(TRobj)- 


A,  o:T\-o:T'^o-\A 


(STmerge)  - 


Ti=T\  A,/2:T2he:ThA1,Z2:T'  Tf/Tf  =»  T3 


A, h-.LM-T,  h 


merged  :  Ti/l2\{e)  :  T  ~> 
merged  :  TJh  :  Tf  ^  r3](e) 


H  Ai,  l2  :  T3 


□ 

6.  CONCLUSION 

Related  Work.  A  lot  of  research  has  been  done  on  typestates  since  they  were  first 
introduced  by  Strom  and  Yemini  [1986].  Most  typestate  analyses  are  whole-program 
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analyses,  which  makes  them  very  flexible  in  handling  aliasing.  Approaches  based  on 
abstract  interpretation  (e.g.  [Fink  et  al.  2008])  rely  on  a  global  alias  analysis  and 
generally  assume  that  the  protocol  implementation  is  correct  and  only  verify  client 
conformance.  Naeem  and  Lhotak  [2008]  developed  an  analysis  for  checking  typestate 
properties  over  multiple  interacting  objects.  These  global  analyses  typically  run  on  the 
complete  code  base,  only  once  a  system  is  fully  implemented,  and  are  time  consuming. 

Fugue  [DeLine  and  Fahndrich  2004]  was  the  first  modular  typestate  verification  sys¬ 
tem  for  object-oriented  software.  It  tracks  objects  as  “not  aliased”  or  “maybe  aliased”; 
only  “not  aliased”  objects  can  change  state.  Bierhoff  and  Aldrich  [2007]  extended 
this  approach  by  supporting  more  expressive  method  specifications  based  on  linear 
logic  [Girard  1987],  They  introduce  the  notion  of  access  permissions  in  order  to  allow 
state  changes  even  in  the  presence  of  aliasing.  They  also  use  fractions,  first  proposed  by 
Boyland  [2003],  to  support  patterns  like  borrowing  and  adoption  [Boyland  and  Retert 
2005],  The  Plural  tool  supports  modular  typestate  checking  with  access  permissions 
for  Java.  It  has  been  used  in  a  number  of  practical  studies  [Bierhoff  et  al.  2009].  Al¬ 
though  Plural  introduced  state  guarantees,  this  paper  provides  their  first  formaliza¬ 
tion.  Nanda  et  al.  [2005]  present  a  system  for  deriving  typestate  information  from  Java 
programs.  In  general,  type  and  typestate  inference  techniques  are  complementary  and 
orthogonal  to  gradual  typing  [Siek  and  Vachharajani  2008]. 

Work  on  distributed  session  types  [Gay  et  al.  2010]  provides  essentially  the  same 
expressiveness  as  Plural,  but  with  protocols  expressed  in  the  structural  setting  of  a 
process  algebra  instead  of  the  setting  of  nominal  typestates.  It  considers  communica¬ 
tion  over  distributed  channels  as  well  as  object  protocols,  but  does  not  allow  aliasing 
for  objects  with  protocols. 

The  above  approaches  do  not  address  typestate-oriented  programming,  as  they  are 
not  integrating  typestates  within  the  programming  model,  but  rather  overlay  static 
typestate  analysis  on  top  of  an  existing  language.  TSOP  has  been  proposed  by  Aldrich 
et  al.  [2009];  its  defining  characteristic  is  supporting  run-time  changes  to  the  rep¬ 
resentation  of  objects  in  the  dynamic  semantics  and  type  system.  The  programming 
language  Plaid8  is  the  first  language  to  integrate  typestates  in  the  core  programming 
model.  Saini  et  al.  [2010]  developed  the  first  core  calculus  for  a  TSOP  language;  their 
language  is  object-based  and  relies  on  structural  types.  Gradual  Featherweight  Type- 
state  builds  on  this  work  but  adapts  it  to  a  class-based,  nominal  approach  with  shared 
access  permissions  and  state  guarantees  for  reasoning  about  typestate  in  the  presence 
of  aliasing.  Earlier  work  related  to  TSOP  includes  the  Fickle  system  [Drossopoulou 
et  al.  2001],  which  can  change  the  class  of  an  object  at  runtime,  but  has  limited  ability 
to  reason  about  the  states  of  an  object’s  fields. 

This  work  also  builds  upon  existing  techniques  for  partial  typing,  like  hybrid  typ¬ 
ing  [Knowles  and  Flanagan  2010]  and  gradual  typing  [Siek  and  Taha  2006,  2007; 
Bierman  et  al.  2010].  Gradual  Featherweight  Typestate  is  a  considerable  advance  in 
this  sense,  by  showing  how  to  gradually  check  flow-sensitive  resources  in  a  modular 
fashion.  Bodden  [2010]  presented  a  hybrid  approach  to  typestate  checking.  A  static 
typestate  analysis  is  performed  to  avoid  unnecessary  instrumentation  of  programs  for 
monitoring  typestates  at  runtime.  While  the  hybrid  perspective  is  shared  with  this 
work,  the  proposed  analysis  is  global.  Turning  a  conventional  alias  analysis  into  a 
modular  analysis  would  require  heavy  low-level  annotations  (such  as  abstract  loca¬ 
tions)  that  are  not  directly  meaningful  to  programmers.  In  contrast,  permissions  are 
designed  to  match  human  abstractions. 

Ahmed  et  al.  [2007]  define  a  core  functional  programming  language  that  supports 
strong  updates,  i.e.  changing  the  type  of  an  object  in  a  reference  cell.  Similarly  to  our 


8Under  development  at  CMU:  http://plaid-lang.org 
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approach,  it  uses  linear  typing.  They  present  two  languages,  L3,  and  extended  L3.  L3 
allows  aliasing,  but  only  has  exclusive  access,  through  a  capability:  only  one  reference 
can  read/write  to  an  object.  In  contrast,  full,  shared  and  pure  access  permissions  allow 
for  more  varied  aliasing  patterns.  Extended  L3  allows  recovering  a  capability,  but  the 
programmer  must  provide  a  proof  that  no  other  capabilities  exist  to  the  reference  cell. 
Extended  L3  is  a  parametrized  framework:  one  must  add  one’s  own  type  system  to 
associate  a  proof  with  the  capability  request. 

Future  Work.  Gradual  Featherweight  Typestate  is  at  the  core  of  the  Plaid  language 
design  project  at  CMU.  We  are  integrating  other  access  permissions  from  Bierhoff 
and  Aldrich  [2007],  and  looking  at  how  a  gradual  type  system  could  support  Plaid’s 
Statechart-like  multidimensional,  compositional  state  model  [Sunshine  et  al.  2011], 
Another  interesting  direction  is  examining  how  gradual  permissions  could  be  lever¬ 
aged  in  Plaid’s  support  for  concurrency  [Stork  2013].  Most  importantly,  we  are  explor¬ 
ing  ways  to  extend  the  power  of  the  static  type  system  in  order  to  avoid  resorting  to 
dynamic  asserts.  An  example  of  such  an  extension  is  permission  borrowing  [Boyland 
and  Retert  2005;  Naden  et  al.  2012],  which,  if  specified  in  method  signatures,  avoids 
having  to  dynamically  reassert  permissions  after  “lending”  them  to  a  sub-computation. 
The  language  we  present  here  already  includes  one  such  refinement,  namely  hold,  used 
to  hold  some  permissions  to  a  reference  while  a  sub-computation  is  performed. 

Importantly,  it  remains  an  outstanding  research  question  if  the  cost  of  dynamic  per¬ 
mission  checking  can  be  amortized  over  the  number  of  permission  checks.  As  it  now 
stands,  enabling  dynamic  permission  checking  mandates  a  fully-instrumented  run¬ 
time  semantics  to  keep  track  of  permissions.  In  Plaid,  we  intend  to  address  this  with 
reference  counting,  not  for  memory  management,  but  for  enabling  runtime  permission 
checks.  Standard  optimization  techniques  like  deferred  increments  [Baker  1994]  and 
update  coalescing  [Levanoni  and  Petrank  2006]  will  be  applied.  We  believe  these  tech¬ 
niques  will  reduce  reference  count  overhead  to  a  small  percentage  of  runtime,  and  will 
study  this  empirically  in  future.  The  formalism  presented  here  establishes  a  baseline 
from  which  to  explore  this  capability  and  develop  new  models  for  permission  tracking. 

Conclusion.  Featherweight  Typestate  (FT)  and  Gradual  Featherweight  Typestate 
(GFT)  are  nominal  core  calculi  for  typestate-oriented  programming.  By  introducing 
typestate  directly  into  the  languages  and  extending  their  type  systems  with  support 
for  gradual  typing,  state  abstractions  can  be  implemented  directly,  stronger  program 
properties  can  be  enforced  statically,  and  when  necessary  dynamic  checks  can  be  in¬ 
troduced  seamlessly.  Both  languages  support  a  rich  set  of  access  permissions  together 
with  state  guarantees  for  substantial  reasoning  about  typestate  in  the  presence  of 
aliasing.  Furthermore,  this  work  paves  the  way  for  further  gradual  approaches  by 
showing  how  to  modularly  and  gradually  check  flow-sensitive  resources. 

REFERENCES 

Ahmed,  A.,  Fluet,  M.,  and  Morrisett,  G.  2007.  L3:  A  linear  language  with  loca¬ 
tions.  Fundamenta  Informaticae  77,  4,  397-449. 

Aldrich,  J.,  Sunshine,  J.,  Saini,  D.,  and  Sparks,  Z.  2009.  Typestate-oriented 
programming.  In  Proc.  Onward!  2009.  ACM,  New  York,  NY,  USA,  1015-1022. 
BAKER,  H.  G.  1994.  Minimizing  reference  count  updating  with  deferred  and  anchored 
pointers  for  functional  data  structures.  SIGPLAN Not.  29,  38-43. 

BIERHOFF,  K.  and  Aldrich,  J.  2007.  Modular  typestate  checking  of  aliased  ob¬ 
jects.  In  Proc.  Conference  on  Object-oriented  Programming  Systems  and  Applica¬ 
tions.  ACM,  New  York,  NY,  USA,  301-320. 


ACM  Transactions  on  Programming  Languages  and  Systems,  Accepted  for  Publication  (May  2014). 


A:40 


R.  Garcia  et  al. 


Bierhoff,  K.,  Beckman,  N.  E.,  and  Aldrich,  J.  2009.  Practical  API  protocol  check¬ 
ing  with  access  permissions.  In  Proc.  European  Conference  on  Object-Oriented  Pro¬ 
gramming.  Springer,  Berlin,  Heidelberg,  195-219. 

BlERMAN,  G.,  Meijer,  E.,  AND  TORGERSEN,  M.  2010.  Adding  dynamic  types  to 
C#.  In  Proc.  European  Conference  on  Object-oriented  Programming.  ECOOP’IO. 
Springer- Verlag,  Berlin,  Heidelberg,  76-100. 

BODDEN,  E.  2010.  Efficient  hybrid  typestate  analysis  by  determining  continuation- 
equivalent  states.  In  Proc.  International  Conference  on  Software  Engineering.  ACM, 
New  York,  NY,  USA,  5-14. 

BOYLAND,  J.  2003.  Checking  interference  with  fractional  permissions.  In  Proc.  Static 
Analysis  (SAS).  Springer- Verlag,  Berlin,  Heidelberg,  55-72. 

BOYLAND,  J.  AND  RETERT,  W.  2005.  Connecting  effects  and  uniqueness  with  adoption. 
In  Symposium  on  Principles  of  Programming  Languages.  ACM,  New  York,  NY,  USA, 
283 — 295. 

DeLine,  R.  AND  FAHNDRICH,  M.  2004.  Typestates  for  objects.  In  Proc.  European 
Conference  on  Object-Oriented  Programming.  Springer,  Berlin,  Heidelberg,  465—490. 

Drossopoulou,  S.,  Damiani,  F.,  Dezani-Ciancaglini,  M.,  AND  Giannini,  P. 
2001.  Fickle:  Dynamic  object  re-classification.  In  Proc.  European  Conference  on 
Object-Oriented  Programming.  Springer- Verlag,  Berlin,  Heidelberg. 

Fink,  S.  J.,  Yahav,  E.,  Dor,  N.,  Ramalingam,  G.,  and  Geay,  E.  2008.  Effec¬ 
tive  typestate  verification  in  the  presence  of  abasing.  ACM  Trans.  Softw.  Eng. 
Methodol.  17,  2,  1-34. 

Gamma,  E.,  Helm,  R.,  Johnson,  R.,  and  Vlissides,  J.  1994.  Design  Patterns: 
Elements  of  Reusable  Object-Oriented  Software.  Professional  Computing  Series. 
Addison-Wesley,  Boston,  MA,  USA. 

Garcia,  R.,  Wolff,  R.,  Tanter,  E.,  and  Aldrich,  J.  2013.  Featherweight  Types¬ 
tate.  Tech.  Rep.  CMU-ISR-13-112,  Carnegie  Mellon  University.  Sept. 

Gay,  S.,  Vasconcelos,  V.,  Ravara,  A.,  Gesbert,  N.,  and  Caldeira,  A.  2010.  Mod¬ 
ular  session  types  for  distributed  object-oriented  programming.  In  Symposium  on 
Principles  of  programming  languages.  ACM,  New  York,  NY,  USA,  299-312. 

GIRARD,  J.-Y.  1987.  Linear  logic.  Theor.  Comput.  Sci.  50,  1,  1-102. 

IGARASHI,  A.,  PIERCE,  B.  C.,  AND  WADLER,  P.  2001.  Featherweight  Java:  a  minimal 
core  calculus  for  Java  and  GJ.  ACM  Trans.  Program.  Lang.  Syst.  23,  3,  396-450. 

JASPAN,  C.  AND  ALDRICH,  J.  2009.  Checking  framework  interactions  with  relation¬ 
ships.  In  Proceedings  of  the  23rd  European  Conference  on  Object-oriented  Program¬ 
ming  (ECOOP  2009),  M.  Mezini,  Ed.  Lecture  Notes  in  Computer  Science  Series,  vol. 
5653.  Springer,  Genova,  Italy,  27-51. 

KNOWLES,  K.  AND  Flanagan,  C.  2010.  Hybrid  type  checking.  ACM  Trans.  Program. 
Lang.  Syst.  32,  2,  6:1-6:34. 

LEVANONI,  Y.  AND  PETRANK,  E.  2006.  An  on-the-fly  reference-counting  garbage  col¬ 
lector  for  Java.  ACM  Trans.  Program.  Lang.  Syst.  28,  1—69. 

Naden,  K.,  Bocchino,  R.,  Aldrich,  J.,  and  Bierhoff,  K.  2012.  A  type  system  for 
borrowing  permissions.  In  Symposium  on  Principles  of  Programming  Languages. 
POPL ’12.  ACM,  New  York,  NY,  USA,  557-570. 

NAEEM,  N.  A.  AND  LhotAk,  O.  2008.  Typestate-like  analysis  of  multiple  interacting 
objects.  In  Proc.  Conference  on  Object-oriented  programming  systems  languages  and 
applications.  ACM,  New  York,  NY,  USA,  347-366. 

Nanda,  M.  G.,  Grothoff,  C.,  and  Chandra,  S.  2005.  Deriving  object  typestates 
in  the  presence  of  inter-object  references.  In  Proc.  Conference  on  Object-oriented 
Programming,  Systems,  Languages,  and  Applications.  ACM,  New  York,  NY,  USA, 
77-96. 


ACM  Transactions  on  Programming  Languages  and  Systems,  Accepted  for  Publication  (May  2014). 


Foundations  of  Typestate-Oriented  Programming 


A:41 


PIERCE,  B.  C.  2002.  Types  and  programming  languages.  MIT  Press,  Cambridge,  MA, 
USA. 

SABRY,  A.  AND  FELLEISEN,  M.  1993.  Reasoning  about  programs  in  continuation¬ 
passing  style.  Lisp  Symb.  Comput.  6,  3-4,  289-360. 

SAINI,  D.,  SUNSHINE,  J.,  and  Aldrich,  J.  2010.  A  theory  of  typestate-oriented  pro¬ 
gramming.  In  Formal  Techniques  for  Java-like  Programs.  ACM,  New  York,  NY,  USA. 

SlEK,  J.  AND  TAHA,  W.  2006.  Gradual  typing  for  functional  languages.  In  Proc.  Scheme 
and  Functional  Programming  Workshop.  ACM,  New  York,  NY. 

SlEK,  J.  AND  TAHA,  W.  2007.  Gradual  typing  for  objects.  In  Proc.  European  Conference 
on  Object-oriented  Programming.  Springer- Verlag,  Berlin,  Heidelberg,  2-27. 

SlEK,  J.  G.  AND  VACHHARAJANI,  M.  2008.  Gradual  typing  with  unification-based 
inference.  In  Proc.  Symposium  on  Dynamic  languages.  ACM,  New  York,  NY,  USA, 
7:1-7:12. 

STORK,  S.  2013.  ASminium:  Freeing  Programmers  from  the  Shackles  of  Sequentiality. 
Ph.D.  thesis,  Carnegie  Mellon  University. 

STROM,  R.  E.  and  Yemini,  S.  1986.  Typestate:  A  programming  language  concept  for 
enhancing  software  reliability.  IEEE  Trans.  Softw.  Eng.  12,  1,  157-171. 

Sunshine,  J.,  Naden,  K.,  Stork,  S.,  Aldrich,  J.,  and  Tanter,  E.  2011.  First- 
class  state  change  in  plaid.  In  Proc.  Object-oriented  Programming,  Systems,  Lan¬ 
guages,  and  Applications.  ACM,  New  York,  NY,  USA. 

WALKER,  D.  2005.  Substructural  type  systems.  In  Advanced  Topics  in  Types  and 
Programming  Languages,  B.  Pierce,  Ed.  MIT  Press,  Cambridge,  MA,  Chapter  1,  3- 
43. 

Wolff,  R.,  Garcia,  R.,  Tanter,  E.,  and  Aldrich,  J.  2011.  Gradual  typestate. 
In  Proceedings  of  the  25th  European  Conference  on  Object-oriented  Programming 
(ECOOP  2011),  M.  Mezini,  Ed.  Lecture  Notes  in  Computer  Science  Series,  vol.  6813. 
Springer,  Lancaster,  UK,  459-483. 

Wolff,  R.,  Garcia,  R.,  Tanter,  E.,  and  Aldrich,  J.  2013.  Gradual  Featherweight 
Typestate.  Tech.  Rep.  CMU-ISR-13-113,  Carnegie  Mellon  University.  Sept. 


ACM  Transactions  on  Programming  Languages  and  Systems,  Accepted  for  Publication  (May  2014). 


A:42 


R.  Garcia  et  al. 


A.  HELPERS 


C  <:C 

Subclass 

fields  (C) 

Class  Field  Declarations 


class  C  extends  D  {  F,  M  } 

C  <:  D 

C  <:C 

C  <:  D  D  <:  E 
C  <:  E 


(fields-object) 


fields  (Object)  =  ■ 


class  C  extends  D  [T  f,  M  } 

fields(D)  =  T7/7 

(fields-subclass) - i  n  i  0  - 

fields(C )  =  T'  /',  T  f 


methodfm,  C) 


Method  Definition 


(method-override) 


class  C  extends  D  {  F,  M  } 

Tr  m(T  »  T'  x )  [Tt  »  Tf]  {  return  e;  }  e  M 

method(m,  C )  =  Tr  m(T  »  T'  x)  [Tt  »  Tf']  {  return  e;  } 


(method-super) 


class  C  extends  D  {  F,  M  }  m$  M 

method(m,  D)  =  Tr  m(T  »  T'  x )  [T)  »  Tf']  {  return  e;  } 

methodfm,  C)  =  Tr  ?n(r  »  T'  x)  [Tt  »  Tf]  {  return  e;  } 


mdecl(m,  C ) 


Method  Declaration 


method(m,  C )  =  Tr  m(T  »  T'  x)  [Tt  »  T/j  {  return  e;  } 

(mdecl) - ^ - - 

mdecl(m,  C )  =  Tr  m(T  »  T')  [Tt  »  Tt'] 


Af  d  ok  in  C 


B.  GFT  PROGRAM  TYPING  RULES 

Well-typed  Method  Declaration 

class  C  extends  D  {  F,  M  } 

mdecl[D,m )  =  Tr  m(Ti  »  T')[Pt  E  »  Tf\ 


Tr  m(Ti  »  T')[Pt  C  »  T/|  ok  in  C 


class  C  extends  D  {  F,M  } 
mdecl(D,m)  undefined 

Tr  m(Ti  »  T')[Pt  C  »  Tt']  ok  in  C 


M  ok  in  C  Well-typed  Method 


Tr  m[Ti  »  T[  x)\Tt  »  Tf]  ok  in  Ct 
~T~i,  this  :Tt\-  e^Tr  this  :  Tf,x  :  Tf 

rp/r  <:  rp 1/  r-pH  -<  ;  rpf 


Tr  m(Ti  »  Tl  x)  [Tt  »  T/]  {  return  e;  }  ok  in  Ct 


F  ok  Well-typed  Field 

CL  ok  Well-typed  Class 

PG  ok  Well-typed  Program 

T[=  T 

F  ok  M  ok  in  Co 

CL  ok  ■  |-  e  =>  T  H  ■ 

T  f  ok 

class  Co  extends  C\  {  F-,  M  }  ok 

(CL,  e>  ok 
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C.  GFT  INTERNAL  LANGUAGE  (GFTIL) 

Well-typed  Expression 


:  T  H  A 


(TIvoid)  - 


A  b  void  :  Void  H  A 


(TIinvoke)  - 


mdecl(m,  C\)  =  Tr  m(T2  »  T^fPi  C\  »  T[\ 


A,  si  :  Pi  C\ ,  S2  ■  T2  \—  si.m(s2)  :  Tr  H  AJ,,si  :  T{,S2  : 

(TIvar-b)  -  A  7  — - — — - — 

A,b  :  T  \-  b  :  T  -\  A 


(Tlinvoke^)- 


A,si  :  Dyn,S2  :  Dyn  |-  si.dm(s2)  :  Dyn  H  A|,si  :  Dyn,S2  :  Dyn 


(TIvar)  - 


Ti  ^  T2/T3 


(TIswap)  - 


A,  s  :  Ti  b  s[Ti  e$  T2/T3]  :  r2  H  A,  s  :  T3 

(T  /)  s  fields  (C)  T  |  T' 


(T2  f)e  fields  (Ci) _ 

A,  si  :  Pi  Cl,s2  :  T2  b 
si.f  :=:  s2  :  T2  H  A,  Si  :  Pi  Ci 


(Tlfield)- 


A,s  :  P  C  h  s.f  :T'  -\  A,s  :  P  C 


(TIswapd)- 


(Tlupdate)  - 


A,  si  :  Dyn,  s2  :  Dyn  b  si.f  :=:d  s2  :  Dyn  H  A,si  :  Dyn 
(Tlfieldd)  ^  g  .  Qyn  |_  s  df  .  Qyn  a,  s  :  Dyn 

fci  e  { full,  shared  }  C[  <:  Di  fields (C[)  =  T2  f 


A,  si  :  ki(Di)  Ci ,  s2  :  T2  b  si  <—  C((s2)  :  Void  H  AJ,,  si  :  fci(Di)  CJ 


(TInew)  - 


(Tlupdated)- 


fields(C)  =  T  f 

A,  s  :  T  b  new  C(s)  :  full(Object)  C  H  A 

_ fields  (C)  =  7^7 _ 

A,  si  :  Dyn,  s2  :  P2  b  si  <-d  Cfsi)  :  Void  H  A|,  si  :  Dyn 

(TIrel)  - 


(Tlholdb 


A,s:Tb  release[T](s)  :  Void  H  A 

Ti  T2/T3  T2{  m  *  T[  A,  s  :  r3  b  e  :  T  H  A',  s  : 

A,  s  :  Ti  b  hold[s  :  Ti  ^  T2/T3  »  T'  ^  T'](e)  :  T  H  A',  s  :  T' 

A  b  ei  :  Ti  H  Ai 
Ai ,  x  :  Ti  b  e2  :  T2  — I  A2 
x  :  Void  6  A2  or  x  :  T[  $  A2 


(Tllet)  - 


A  b  let  x  =  ei  in  e2  :  T2  H  A2  b  a; 


(TImerge) 


Ti  =  Tif  Ti/T'  ^  T3 
A,  f2  :  T2  b  e  :  T  H  A',  Z2  :  T^ 

A,Zi  :  Ti,z2  :  T2  b  merge[Zi  :  T\/T2  ■  T'  ^  T3](e)  :  T  b  A',  l2  :  T3 


(TIassert) 


_ T  T' _ 

A,  s  :  T  b  assert(T  »  T')(s)  :  Void  H  A,  s  :  T' 


(TIassert,/) 


T  T' 

A,  s  :  T  b  assert/j^T  »  T')(s)  :  Void  H  A,  s  :  T' 
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N  ok  in  C 


Well-typed  Method  Signatures 

class  C  extends  D  {  F,  M  } 
mdccl(I) .  rn)  =  Tr  rn(Tz  »  T')[Pt  E  »  T('] 

Tr  m(r,  »  T')[Pi  C  »  T']  ok  in  C 


class  C  extends  D  {  F,M  } 
mdecl(D,m )  undefined 

Tr  m(T\^T[)[Pt  C  »  T/]  ok  in  C 


M  ok  in  C 


Well-typed  Method 


Tr  m{Ti  »  T[  x)[Tt  »  T[]  ok  in  Ct 
this  :  Tt,  x  :  Ti  |-  e  :Tr  H  this  :  T[,  x  :  T[ 

Tr  m(Ti  »  T[  x)  [Tt  »  Tt']  {  return  e;  }  ok  in  Ct 


F  ok  Well-typed  Field 

CL  ok  Well-typed  Class 

PG  ok  Well-typed  Program 

T|=  T 

F  ok  M  ok  in  Co 

CL  ok  ■  h  e  :  T  H  ■ 

Tf  ok 

class  Co  extends  Cl  {  F\  M  }  ok 

(CL,  e)  ok 
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p,  p,  e  — *  p,  p ,  e 


Dynamic  Semantics 


(GElookup-binder) - — 

P,  P,  l  -»  PiPiPlO 


(GEnew) 


o  ^  dom(p) 


p'  =  p[0  i-^-  C(p(0)  [full (Object)]] 
p,  p,  new  (7(1)  — >  /a',  p,  o 


(GElookup-obj) 


p'  =  P  -  P(Q  ••  Ti  +  p(Q  :  r2  +  p(l)  :  r3 
p,  p,  l[Ti  ^  T2/T3 ]  — >  p',  p,  p(l) 


(GErel) 


p'  =  P  ~  P(0  ■  T 
p,p,  release[T](t)  — >p',p,void 


(GEswap) 


(GEinvoke) 


(GEswapd) 


>  p(p(D)  = 

C(o)  P 

fields  (C)  =  T  f 

p,  P.  h-fi 

:=:  h  — 

p[p(L) 

[pC^2  )/ 

Oi]C(o)  P],p,Oi 

p(p(;  i))  = 

C(o)F 

method (m,  C)  = 

Tr  m(Ti  » 

s)  [T* 

»  T/]  {  return  e;  } 

p,  /i.m 

,(t2)  -»  p, 

P,  [fi,f2/this,x]e 

p(p(f  i))  = 

=  C(o)  P 

fields  (C)  =  T/ 

Da 

=  A  {£> 

fc(£>)  6  P} 

Pi  Pi  ll-fi 

—  :d  *2  -♦ 

/lx,  p,  assertd(Dyn  »  shared(Dg)  (7>(Zi); 
assertd<Dyn  »  T*>(Z 2); 
letret  =  /i./^  :  =  :  I2  in 

assert<shared(Dg)  C  »  Dyn)(/i); 

assert(Tj  »  Dyn)(ret); 

ret 


(GEinvoke^) 


p(p(f  1))  -  C(o)  P 

mdecl(m,  C)  =  Tr  m(T,  »  T')  [Tt  »  T/] 

_ I  71  1  =  1  5  I _ 

p,  p,  ti.dm(t2)  ->  p,  p,  assertd(Dyn  »  Tf)(fi); 

assertd<Dyn  »  Ti)(h)', 
let  ret  =  ij ,m(l 2)  in 
assert (Tj.  »  Dyn)(ii); 
assert<Tj'  »  Dyn>(t2); 
assert(Tr  »  Dyn)(ret); 
ret 


(GEupdate) 


p(p(il))  =  C(o)  P _  _  fields (C)  =  T  f 

Pi  =  p[p(fl)  C"(p(t2))  P ]  p'  =  pi  -  o  :  T 

p,  p,  ti  «-  C'(72)  — ►  p',  p.  void 
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(GEupdated) 


f*wy)  =  c<pj)  p 

Dg  =  A  {D  j  k(D)  e  P}  C'  <:  Dg 

P,P,h  «- d  C'©- 
/i,p, assertd<Dyn  »  shared(P>9)  C>©; 
«i  <-  C"©; 

assert<shared(£>3)  C'  »  Dyn)(/i) 


(GEfield)  ■ 


mO( 0)  =  C(o)  P  fields (C)  =  T  f 
Ti  §T'  p'  =  p  +  Oi  :  T' 


P,P,l-fi 


(GEassert)- 


p'  =  P~  p{  0  :  T  +  p(l) 


■  p' ,  p,  Oi  p,  p,  assert(T  »  T')(i)  — >  p' 

p{p{l))  =  C{o)  P  fields  (C)  =  T~f 


(GEfieldd)- 


(GEassert,/ v) 


P,P,l-dfi  —  P,P,Oi 
p(l)  =  void 


(GEassertdO)- 


p,  p,  assertd<Dyn  »  Void)(i)  — ►  p,  p,  void 
p(  0  =  o 

p!  =  p  —  o  :  T  +  o  :  P'  C' 
p'{o)  =  C(oj)P 
C  <:  C'  P  compatible 


(GEhold)  - 


p,  p,  assertd(T  »  P'  C,')(l)  — >  p/,p,void 

p'  =  p  —  p(l)  ■  Ti  +  p(l)  :  T2  +  p(l)  :T3  V  $  dom(p)  p'  =  p[l'  >->  p(Z)] 
p,p,  hold[Z  :  Ti  ^  T2/T3  »  =*•  T[]{e)  -+  p',p',merge[l'  :  T2[  /l  :  T3  =*•  T{](e) 

p'  =  P  —  p(l')  ■■  Ti  -  p(l)  :  T2  +  p(l)  :  r3 


(GEmerge) 

(GEmcongr) 


(GElet) 


(GEcongr)  - 


P,P,  merged'  :  Ti/Z  :  T2  ^  T3](v)  -►  p,  ^ 

/lx,  p,  e  — ►  p' ,  p' ,  e' 

H,p,  merge[/i  :  T/Z2](e)  -»  p' , p' ,  merge [h  :  T//2](e') 
Z  ^  dom(p) 


p,  p,  let  x  =  v  in  e  — ►  p,  p[Z  »— ►  t>],  [//x]e 


p,p,  e  1  ^  fj,',p\e'1 


p,  p,  let  rr  =  ei  in  e2  — >  p  ,  p',  let  :r  =  eC  in  e2 


:  T* 

,  p,  void 
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D.  TYPE-DIRECTED  TRANSLATION  FROM  GFT  TO  GFTIL 

M  M1  Method  Translation 

this  :  Tt,  x  :  T  h  e  :  Tr  e1  -\  this  :  T" ,  x  :  T" 
ex  =  let  ret  =  eJ  in  coerce(this,  T" ,  T/);  coerce(x,T" ,T');ret 

Tr  m{T  »  T’  x)  [Tt  »  Tt']  {  return  e;  }  Tr  m(T  »  T'  x )  [Tt  »  Tt']  {  return  ex ;  } 


CL  CL  |  Class  Translation 

_ F  F1  M^M1 _ 

class  Co  extends  Ci  {  F;  M  } 

class  C0  extends  Ci  {  F1-,  Mx  } 


PG  '■->  PC1  Program  Translation 

•  I-  e  :  T  ^  ex  H  ■  CL  Chz 
(CL,  e>  (CL1,  ex> 
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